limited range of data error

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/

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/

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/

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

quoted

   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/

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/

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/

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/