limited range of data error

limited range of data error

[Rhys]

When i try to compile i get these errors:

act_comm.c: In function 'send_ascii_title':
act_comm.c:2234: warning: comparison is always true due to
limited range of data type

This is from a redhat system. I think there are
problems with me missing the files related to
fgetc() and fopen(). Anyone have any ideas for
how to get this to work?

Relevent code is:

send_ascii_title( CHAR_DATA *ch )
{
   FILE *rpfile;
   int num=0;
   char BUFF[MAX_STRING_LENGTH];

   if ((rpfile = fopen(ASCTITTLE_FILE, "r")) !=NULL) {
     while (( BUFF[num]=fgetc(rpfile)) != OEF) // Line 2234
        num++;
     fclose(rpfile);
   BUFF[num] = 0;
   write_to_buffer( ch->desc, BUFF, num );
   }
}

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: limited range of data error

[Gabriel Paubert]

On Mon, 20 Mar 100, Rhys wrote:

>
> When i try to compile i get these errors:
>
> act_comm.c: In function 'send_ascii_title':
> act_comm.c:2234: warning: comparison is always true due to
> limited range of data type

Classical problem: don't assign the return value of fgetc to a char before
checking for EOF.

By definition, fgetc returns an unsigned char cast to an int or eof. On
machines on which char is signed by default, this seems to work in most
cases, except that one day char \0xff will be taken for eof. And yes there
are charsets in which \0xff may be used. Just feed a normal text file in
which you have a Latin-1 lowercase y with diaeresis, and watch for bugs in
most text processing programs.

Using the compiler option -fsigned-char only hides the problem. It does
not solve it. Actually, because of this convention, nothing should ever be
compiled with -fsigned-char and you should use -funsigned-char on _all_
platforms since it implicitly checks for some stupid bugs like this one,
thereby showing the intrinsic superiority of unsigned chars.


> This is from a redhat system. I think there are
> problems with me missing the files related to
> fgetc() and fopen(). Anyone have any ideas for
> how to get this to work?
>
> Relevent code is:
>

Oh, BTW, this code is not very well protected against buffer overflows, to
put it mildly. But I leave it up to you.

	Gabriel.

(hand built unified diff, no line numbers or other cruft)
  send_ascii_title( CHAR_DATA *ch )
  {
     FILE *rpfile;
-    int num=0;
+    int num=0, tmp;

     char BUFF[MAX_STRING_LENGTH];

     if ((rpfile = fopen(ASCTITTLE_FILE, "r")) !=NULL) {
-      while (( BUFF[num]=fgetc(rpfile)) != OEF) // Line 2234
-         num++;
+      while (( tmp=fgetc(rpfile)) != EOF) // Line 2234
+	 BUFF[num++] = tmp;
       fclose(rpfile);
     BUFF[num] = 0;
     write_to_buffer( ch->desc, BUFF, num );
     }
  }



>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: limited range of data error

[David A. Gatwood]

On Mon, 20 Mar 100, Rhys wrote:

> When i try to compile i get these errors:

> act_comm.c:2234: warning: comparison is always true due to
> limited range of data type

>    char BUFF[MAX_STRING_LENGTH];
>
>    if ((rpfile = fopen(ASCTITTLE_FILE, "r")) !=NULL) {
>      while (( BUFF[num]=fgetc(rpfile)) != OEF) // Line 2234

I assume that's EOF, and not OEF.  Anyway, this can be fixed by making
BUFF[] be an array of signed char instead of just char.  Ran into the same
issue this past wekend in some code I was writing.


Later,
David

---------------------------------------------------------------------
A logician trying to explain logic to a programmer is like a cat
trying to explain to a fish what it's like to be wet.

	-- unknown, possibly Franklin Veaux


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: limited range of data error

[Gabriel Paubert]

On Mon, 20 Mar 2000, David A. Gatwood wrote:

> >    if ((rpfile = fopen(ASCTITTLE_FILE, "r")) !=NULL) {
> >      while (( BUFF[num]=fgetc(rpfile)) != OEF) // Line 2234
>
> I assume that's EOF, and not OEF.  Anyway, this can be fixed by making
> BUFF[] be an array of signed char instead of just char.  Ran into the same
> issue this past wekend in some code I was writing.

This is the quick, dirty and _wrong_ fix since it does not distinguish
EOF from '\0xff'. See my other post, and sorry for being harsh, but I'm
extremely upset about this and all the code compiled with -fsigned-char
whose most important effect is to hide precisely this bug, by curing the
symptom and not the cause.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

stty crtscts < /dev/ttyS1

[DeRobertis]

Hardware flow control is broken. The command in the subject line (stty
crtscts < /dev/ttyS1) freezes linux 2.2.14. Any idea why?

I've already grabbed the latest stty.

Oddly, the following line in /etc/ppp/options does not freeze:
	/dev/modem 57600 crtscts

(/dev/modem is a symlink to /dev/ttyS0)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1

[Matt Haffner]

DeRobertis wrote:
>
> Hardware flow control is broken. The command in the subject line (stty
> crtscts < /dev/ttyS1) freezes linux 2.2.14. Any idea why?

Try this syntax: "stty -F /dev/ttyS1 crtscts". There's a comment in the
info doc for stty that letting the shell open the device may block in
certain situations.

mh
--
Matt Haffner                      /|------|\    University of Wisconsin
Dept. of Astronomy               /|--------|\            Madison
haffner@astro.wisc.edu          /|----------|\
           WHAM project -- http://www.astro.wisc.edu/wham

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1 [603ev]

[ce]

 Matt Haffner }  >Try this syntax: "stty -F /dev/ttyS1 crtscts". There's a comment in the
 Matt Haffner }  >info doc for stty that letting the shell open the device may block in
 Matt Haffner }  >certain situations.
 DeRobertis }
 DeRobertis }  Does not help. Same problem. Let me clarify "freeze", though. I mean it
 DeRobertis }  takes out the machine -- the kernel does not run processes. The machine
 DeRobertis }  might as well be turned off; it'd do as much good.
 DeRobertis }
 DeRobertis }  Unfortunately, no oopses. No backtraces. No entries in
 DeRobertis }  /var/log/messages. Nothing. It just dies.
 DeRobertis }
 DeRobertis }  A rather serious kernel bug, IMO.
 DeRobertis }
 DeRobertis }  cc'd to l-k. It's 2.2.14 running on a ppp-603ev.

 same story on my pb3400_603ev, but an old one, even with 2.1.85 as far as I remember correctly. The second try to influence ttyS0 via stty [now 2.2.14] stops everything as you described, a little bit annoying. Perhaps a problem of our special RS?
People like Paul M. have been working with a pb3400, do you know others?

greetings Claus

--
>45. Id. at 50-51; Lewinsky 8/6/98 GJ at 21.
>On this occasion, the President ejaculated. Lewinsky 8/26/98 Depo. at 50-51.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1 [603ev]

[DeRobertis]

> same story on my pb3400_603ev, but an old one, even with 2.1.85 as
>far as I remember correctly. The second try to influence ttyS0 via
>stty [now 2.2.14] stops everything as you described, a little bit
>annoying. Perhaps a problem of our special RS?
>People like Paul M. have been working with a pb3400, do you know others?

I don't know -- I'm on a PowerBase 200 dekstop. Wish I had a nice laptop :)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

communicate with peripherics ?

[Franck Chionna]

hi,

i have connected on printer serial port of my 9600 Power mac
an electronic payment terminal. So i'd like to communicate with it to
develop an application to automate this peripherals ...
with what way could i communicate with it ??

Thansk

Franck Chionna


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1

[Giuliano Pochini]

> >> Hardware flow control is broken. The command in the subject line (stty
> >> crtscts < /dev/ttyS1) freezes linux 2.2.14. Any idea why?
> >
> >Try this syntax: "stty -F /dev/ttyS1 crtscts". There's a comment in the
> >info doc for stty that letting the shell open the device may block in
> >certain situations.
>
> Does not help -- still freezes.
>
> By freezes I mean that the kernel dies. It no longer responds to
> keypresses. It no longer runs processes. All that I can do is hit reset.

What is connected to the serial port ?  When I enable RTS/CTS on ttyS1
and there is my Epson 740 attached, the whole system freezed. I don't
know why this happen exactly. It seems that the printer changes continuosly
with very high frequency  the state of CTS, which cause the serial driver
to loop indefinitely. When I detach the cable, Linux awakes. It also happens
with BeOS, but not under MacOS.
RTS/CTS works fine when I connect the serial port to the modem or to
another computer.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1

[DeRobertis]

At 8:35 PM -0400 on 4/7/00, Giuliano Pochini wrote:

>What is connected to the serial port ?  When I enable RTS/CTS on ttyS1
>and there is my Epson 740 attached, the whole system freezed.

Same thing attached.

>I don't
>know why this happen exactly. It seems that the printer changes continuosly
>with very high frequency  the state of CTS, which cause the serial driver
>to loop indefinitely.

Ouch! Broken hardware... how can I document this is happening, so that
I can demand an answer from Epson?

Or maybe I should just hack the serial driver to ignore this. And WTF
is the serial driver doing looking at CTS on a port with no data?!


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1

[Greg Noel]

At 8:35 PM -0400 on 4/7/00, Giuliano Pochini wrote:

>I don't know why this happen exactly. It seems that the printer changes
>continuosly with very high frequency the state of CTS, which cause the
>serial driver to loop indefinitely.

At 12:05 AM -0400 4/8/00, DeRobertis replied:

>Ouch! Broken hardware... how can I document this is happening, so that
>I can demand an answer from Epson?

>From your messages, it's not clear to me that it's the printer.  It could
easily be the cable.  Try replacing the cable with one that only connects
the signals you're using and properly grounds all the other signals.

In a previous life, I had this sort of problem with a serial cable that let
RI (ring) float, so it acted like an antenna.  It picked up an another
signal in the cable that was running at 9600 baud (which was really fast at
the time).  It looked to the computer as if the phone was ringing 4800
times per second and each "ring" caused an interrupt so it could enable the
modem.  That was more than enough to drive it to its knees.

>Or maybe I should just hack the serial driver to ignore this. And WTF
>is the serial driver doing looking at CTS on a port with no data?!

If there are multiple ports, it may not be possible to disable a specific
interrupt for an individual port, so it always has to be enabled in case
any port needs it.  That was the case with the hardware I had.

Hope this helps,
-- Greg Noel, retired UNIX guru

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1

[Giuliano Pochini]

> >Ouch! Broken hardware... how can I document this is happening, so that
> >I can demand an answer from Epson?
>
> >From your messages, it's not clear to me that it's the printer.  It could
> easily be the cable.  Try replacing the cable with one that only connects
> the signals you're using and properly grounds all the other signals.

The Epson 740 comes with a MAC-style serial connector and I'm using a standard
Apple serial cable. There are no floating pins.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1

[DeRobertis]

At 9:08 AM -0800 on 4/8/00, Greg Noel wrote:
>At 8:35 PM -0400 on 4/7/00, Giuliano Pochini wrote:
>
>>I don't know why this happen exactly. It seems that the printer changes
>>continuosly with very high frequency the state of CTS, which cause the
>>serial driver to loop indefinitely.
>
>At 12:05 AM -0400 4/8/00, DeRobertis replied:
>
>>Ouch! Broken hardware... how can I document this is happening, so that
>>I can demand an answer from Epson?
>
>From your messages, it's not clear to me that it's the printer.  It could
>easily be the cable.  Try replacing the cable with one that only connects
>the signals you're using and properly grounds all the other signals.

It's a Mac DIN-8 (I think that's the name) cable; I don't believe there
are any unused signals. And pulling the printer off the remote end or
the cable out of the local end both unfreeze linux. Same with turning
off the printer.

>>Or maybe I should just hack the serial driver to ignore this. And WTF
>>is the serial driver doing looking at CTS on a port with no data?!
>
>If there are multiple ports, it may not be possible to disable a specific
>interrupt for an individual port, so it always has to be enabled in case
>any port needs it.  That was the case with the hardware I had.

Same hardware does not kill the MacOS -- even when it's using the port.
Seems like a Linux problem.

However, I've come up with something interesting -- to run a Mac serial
port at the speed the printer's docs say it can (1.8Mbps), you need
external clocking... more on this in another message.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: stty crtscts < /dev/ttyS1

[Giuliano Pochini]

> >What is connected to the serial port ?  When I enable RTS/CTS on ttyS1
> >and there is my Epson 740 attached, the whole system freezed.
>
> Same thing attached.

It could be a bug in the serial driver, but I don't think so. BeOS hangs
same way (although it's likely Be people "ported" Linux code into BeOS...).
I spent a couple of days around the serial driver and I didn't find any bug.
BTW under MacOS it works fine :-/  so what ???

> >I don't
> >know why this happen exactly. It seems that the printer changes continuosly
> >with very high frequency  the state of CTS, which cause the serial driver
> >to loop indefinitely.
>
> Ouch! Broken hardware... how can I document this is happening, so that
> I can demand an answer from Epson ?

To print under Linux I wrote a small prg which sends data to the printer very
slowly bacause I couldn't find a way to know when the printer buffer gets
filled. Somewhere at Epson (about older printers) I read that it should use
starndard rts/cts flow control.
Ah, I send data at 230400bps 8N2 (*2* stop bits) because the printer don't
seem to be able to receive data so quickly (again, no problems with 8N1
under MacOS).

> Or maybe I should just hack the serial driver to ignore this.

:-6

> And WTF
> is the serial driver doing looking at CTS on a port with no data?!

CTS changes cause and interrupt.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/