Does the Char_t declaration not take into account signed and unsignedness of the variables? In particular, I thought if you used Char_t, it would always be signed and if you used UChar_t, it would always be unsigned? Kris Christian Holm Christensen wrote: > Hi Steve, > > On Sun, 18 Mar 2001 20:47:45 -0600 > "Stephen J. Sanders" <ssanders@ukans.edu> wrote > concerning ": problem with compiling BrDb.cxx": > > Hi, I recently checked out the complete brat to work on the revised > > mult code. However, when compiling BrDb.cxx the make stopped with: > > > > cc1plus: warnings being treated as errors > > BrDb.cxx: In method `Bool_t BrDb::ReadBratDbRc(const char *, const char > > *, char > > *&, char *&)': > > BrDb.cxx:249: warning: comparison is always false due to limited range > > of data t > > ype > > make[1]: *** [../obj/linux/BrDb.o] Error 1 > > make[1]: Leaving directory `/home/sanders/Brahms/brat/db/src' > > > > The problem statement is: > > > > if (c == EOF) break; > > The problem is, for some reason, datatype 'char' is unsigned on your > platform/compiler/C library, and 'EOF' is an 'int' with the value > -1. So 'c', being and char (unsigend), can never ever by -1, and so > the comparison above will always be false (like the error message > says). > > Here's what the GCC manual (EGCS 1.1.2) has to say on the signedness > of 'char' > > Ideally, a portable program should always use `signed char' or > `unsigned char' when it depends on the signedness of an object. > ... > > The type `char' is always a distinct type from each of `signed > char' or `unsigned char', even though its behavior is always just > like one of those two. > > > I was able to fix the problem by explicitly casting EOF with > > > > if(c==(char) EOF) break; > > The explicit cast is not a good idea here, since the condition will > anyway allways be false, which ofcourse defies the purpose of the > test. > > I signed the datatype of 'c' to be 'signed char' and it worked > fine. I've commited the change to CVS. Please try it out and let me > know of there's a problem. > > How are you doing on ROOT 3.00/06? > > Thanks Steve for brining this up. I knew that 'char' could be signed > or unsigned depending on the architecture, but I wasn't aware that it > could be a problem in this kind of code. Good stable and portable code > is a very good thing, so if anyone knows of anything similar > other places in the code, please correct it. > > > The rest of the build went OK. > > I don't want to commit this change to the cvs without having a better > > idea of possilbe consequences. > > Christian, is the casting OK? I'm running a LinuxPPC system on a mac > > with the 2.4.2 kernel. and > > version 2.95.3 of g++. > > Fancy stuff uh. Latest kernel, odd GCC, on a RISC processor. Do you > have a dual boot system (i.e., Linux + MacOS), and if so have you > tried to build ROOT/BRAT on MacOS? That'd be interresting, especially > if it't the new version (read: Unix-clone) of MacOS. > > Yours, > > Christian ----------------------------------------------------------- > Holm Christensen Phone: (+45) 35 35 96 91 > Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 > DK-2200 Copenhagen N Web: www.nbi.dk/~cholm > Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b29 : Mon Mar 19 2001 - 13:07:48 EST