Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 20011227T200851+0100, Gerhard Tonn wrote: > I grepped my archived build logs and found that all packages below have got > this problem. Bzzz, wrong assumption. You should have read the code. The warning you cite can be the result of other problems, and it also can be a non-problem. The last is the case with catdvi, which your list includes. The line in catdvi that gets this warning is if ((b >= DVI_set_char_0) && (b <= DVI_set_char_127)) Now, DVI_set_char_0 happens to be defined as 0, and I could have in principle omitted the test, but I prefer this formulation as it is IMHO clearer. In the above code, b is declared as a "byte", which is in turn a typedef for unsigned char. -- Antti-Juhani Kaijanaho, LuK (BSc)* http://www.iki.fi/gaia/ * [EMAIL PROTECTED] assistentti (ohjelmistotekniikka) / assistant in software engineering Jyväskylän yliopisto, tietotekniikan laitos University of Jyväskylä, Department of Mathematical Information Technology
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 06-Jan-02, 04:55 (CST), Adrian Bunk <[EMAIL PROTECTED]> wrote: > > You need to do this in a portable way so that it works on every system... No, the people who want modern code to run on their systems need to figure out how to support the standard. Why should every piece of code contain the work-arounds to support broken systems, rather than expecting the systems to solve their own problems? > It's the choice of the author of a program whether he wants to support > older systems or not - Exactly. It's not required, and shouldn't even be expected. I'd much rather an author spent time adding features, or writing docs, or even relaxing with Quake than waste it supporting the 1993 version of Piece-o'-Crap OS. But that's my opinion, and if some one feels the need, then that's up to them. >I remember that e.g. many GNU programs still support > pre-ANSI C compilers. Which is really sad. It makes the code harder to read, and provides ample opportunity for subtle bugs when the standard code path is updated, and the non-standard one isn't. The only thing that really needs to support pre-ansi compilers is gcc (and possibly GNU make). Anyway, I suppose this is off-topic enough. The original point was that most people don't even know how to write standard conforming code, much less adjust for supporting systems that aren't. Steve
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Fri, 4 Jan 2002, Steve Greenland wrote: > > If every system had up-to-date, standards-conforming > > ctype.h support, we wouldn't have to worry much at all. > > But even these days, pretty many systems with buggy macros > > are still in use. > > Then fix those systems. Pull the necessary stuff out of glibc and use > it rather than the system headers/libc. You need to do this in a portable way so that it works on every system... > > FYI, as far as I know, the most portable way to use > > the ctype macros is to define wrapper macros > > (e.g., like those below, from fileutils/src/sys2.h) > > and then use only the wrappers (upper-case names) from your code. > > > What an abomination. I spent way too much of my youth doing crap like > this. I'm tired of it. The standard has been in place for 12 fscking > years. If the vendors aren't going to support it, then those systems > are dead. I've better things to do with my time than make ugly code to > support systems that haven't been upgraded for over a decade. > It's the choice of the author of a program whether he wants to support older systems or not - and if he wants to support older systems (and many older systems are still running) or systems that don't confirm to a standard he won't accept patches that limit the number of systems his program runs on. I remember that e.g. many GNU programs still support pre-ANSI C compilers. > Steve cu Adrian
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 04-Jan-02, 09:09 (CST), Jim Meyering <[EMAIL PROTECTED]> wrote: > > If every system had up-to-date, standards-conforming > ctype.h support, we wouldn't have to worry much at all. > But even these days, pretty many systems with buggy macros > are still in use. Then fix those systems. Pull the necessary stuff out of glibc and use it rather than the system headers/libc. > FYI, as far as I know, the most portable way to use > the ctype macros is to define wrapper macros > (e.g., like those below, from fileutils/src/sys2.h) > and then use only the wrappers (upper-case names) from your code. What an abomination. I spent way too much of my youth doing crap like this. I'm tired of it. The standard has been in place for 12 fscking years. If the vendors aren't going to support it, then those systems are dead. I've better things to do with my time than make ugly code to support systems that haven't been upgraded for over a decade. Steve -- Steve Greenland
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Jim Meyering <[EMAIL PROTECTED]> writes: > If every system had up-to-date, standards-conforming ctype.h > support, we wouldn't have to worry much at all. But even these > days, pretty many systems with buggy macros are still in use. Surely these aren't Debian systems? If so, we should get those systems fixed. [useful information on portable programming snipped] Kjetil T.
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Ganesan R <[EMAIL PROTECTED]> wrote: >> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes: >> On 31-Dec-01, 19:42 (CST), Ganesan R <[EMAIL PROTECTED]> wrote: >>> Another thing that puzzles me since this whole debate started. If you look >>> at the declaration of ctype.h functions (isalpha family), they take a int as >>> an argument. > >> I don't know that I agree about needing to pass them unsigned char, >> though. The char->int conversion should be value preserving. If you pass >> a negative value, then you are making a domain error, and deserve what >> you get. > > Are you saying that isalpha() etc should work for negative values or that > you should never call isalpha() with negative values for chars? In a > ISO8859-1 locale when I call isalpha() for accented characters I should get > expected results without worrying about whether the accented character is a > signed quantity. Unfortunately older C library implementations may break > because an accented character will take a negative index on a character > table without proper casting. > > I followed up a bit on this and found out that ISO C specifically states > that ctype functions should work for all values of unsigned char as well as > the default char type. In other words, if the default C char type is signed > you can just call the functions without any cast and expect it to work. If every system had up-to-date, standards-conforming ctype.h support, we wouldn't have to worry much at all. But even these days, pretty many systems with buggy macros are still in use. FYI, as far as I know, the most portable way to use the ctype macros is to define wrapper macros (e.g., like those below, from fileutils/src/sys2.h) and then use only the wrappers (upper-case names) from your code. Of course, the following assumes you have the right definitions for STDC_HEADERS and HAVE_ISASCII. You get those by using these autoconf macros: AC_HEADER_STDC AC_CHECK_FUNCS(isascii) Be careful when choosing between ISDIGIT and ISDIGIT_LOCALE. Jim #include "config.h" #include /* [someone :-)] writes: "... Some ctype macros are valid only for character codes that isascii says are ASCII (SGI's IRIX-4.0.5 is one such system --when using /bin/cc or gcc but without giving an ansi option). So, all ctype uses should be through macros like ISPRINT... If STDC_HEADERS is defined, then autoconf has verified that the ctype macros don't need to be guarded with references to isascii. ... Defining isascii to 1 should let any compiler worth its salt eliminate the && through constant folding." Bruno Haible adds: "... Furthermore, isupper(c) etc. have an undefined result if c is outside the range -1 <= c <= 255. One is tempted to write isupper(c) with c being of type `char', but this is wrong if c is an 8-bit character >= 128 which gets sign-extended to a negative value. The macro ISUPPER protects against this as well." */ #if STDC_HEADERS || (!defined (isascii) && !HAVE_ISASCII) # define IN_CTYPE_DOMAIN(c) 1 #else # define IN_CTYPE_DOMAIN(c) isascii(c) #endif #ifdef isblank # define ISBLANK(c) (IN_CTYPE_DOMAIN (c) && isblank (c)) #else # define ISBLANK(c) ((c) == ' ' || (c) == '\t') #endif #ifdef isgraph # define ISGRAPH(c) (IN_CTYPE_DOMAIN (c) && isgraph (c)) #else # define ISGRAPH(c) (IN_CTYPE_DOMAIN (c) && isprint (c) && !isspace (c)) #endif /* This is defined in on at least Solaris2.6 systems. */ #undef ISPRINT #define ISPRINT(c) (IN_CTYPE_DOMAIN (c) && isprint (c)) #define ISALNUM(c) (IN_CTYPE_DOMAIN (c) && isalnum (c)) #define ISALPHA(c) (IN_CTYPE_DOMAIN (c) && isalpha (c)) #define ISCNTRL(c) (IN_CTYPE_DOMAIN (c) && iscntrl (c)) #define ISLOWER(c) (IN_CTYPE_DOMAIN (c) && islower (c)) #define ISPUNCT(c) (IN_CTYPE_DOMAIN (c) && ispunct (c)) #define ISSPACE(c) (IN_CTYPE_DOMAIN (c) && isspace (c)) #define ISUPPER(c) (IN_CTYPE_DOMAIN (c) && isupper (c)) #define ISXDIGIT(c) (IN_CTYPE_DOMAIN (c) && isxdigit (c)) #define ISDIGIT_LOCALE(c) (IN_CTYPE_DOMAIN (c) && isdigit (c)) #if STDC_HEADERS # define TOLOWER(Ch) tolower (Ch) # define TOUPPER(Ch) toupper (Ch) #else # define TOLOWER(Ch) (ISUPPER (Ch) ? tolower (Ch) : (Ch)) # define TOUPPER(Ch) (ISLOWER (Ch) ? toupper (Ch) : (Ch)) #endif /* ISDIGIT differs from ISDIGIT_LOCALE, as follows: - Its arg may be any int or unsigned int; it need not be an unsigned char. - It's guaranteed to evaluate its argument exactly once. - It's typically faster. Posix 1003.2-1992 section 2.5.2.1 page 50 lines 1556-1558 says that only '0' through '9' are digits. Prefer ISDIGIT to ISDIGIT_LOCALE unless it's important to use the locale's definition of `digit' even when the host does not conform to Posix. */ #define ISDIGIT(c) ((unsigned) (c) - '0' <= 9)
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes: > On 31-Dec-01, 19:42 (CST), Ganesan R <[EMAIL PROTECTED]> wrote: >> Another thing that puzzles me since this whole debate started. If you look >> at the declaration of ctype.h functions (isalpha family), they take a int as >> an argument. > I don't know that I agree about needing to pass them unsigned char, > though. The char->int conversion should be value preserving. If you pass > a negative value, then you are making a domain error, and deserve what > you get. Are you saying that isalpha() etc should work for negative values or that you should never call isalpha() with negative values for chars? In a ISO8859-1 locale when I call isalpha() for accented characters I should get expected results without worrying about whether the accented character is a signed quantity. Unfortunately older C library implementations may break because an accented character will take a negative index on a character table without proper casting. I followed up a bit on this and found out that ISO C specifically states that ctype functions should work for all values of unsigned char as well as the default char type. In other words, if the default C char type is signed you can just call the functions without any cast and expect it to work. Ganesan
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 31-Dec-01, 19:42 (CST), Ganesan R <[EMAIL PROTECTED]> wrote: > Another thing that puzzles me since this whole debate started. If you look > at the declaration of ctype.h functions (isalpha family), they take a int as > an argument. The reason the argument for these is int is a relic of the dark ages, aka K&R C. Before function prototypes, there was no way to pass a real char (or short) to a function: such arguments were promoted to int. (Likewise, float was promoted to double -- thus all the math.h functions taking double args.) I don't know that I agree about needing to pass them unsigned char, though. The char->int conversion should be value preserving. If you pass a negative value, then you are making a domain error, and deserve what you get. Steve
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Ganesan R writes:
> On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote:
>> It can't be larger than 255 (precisely because it is limited to a single
>> byte).
>> The more I think about it, the more it makes sense to always explicitly
>> declare all char variables as signed or unsigned; otherwise, you're just
>> asking for latent bugs.
Do remember that people port to systems other than Linux with gcc.
IIRC 'signed char' is not available in pre-ANSI C. Code that was
written to be compilable on those platforms will use plain char and
extra checks. For such code, these 'comparison is always {true|false}
due to limited range of datatype' messages are just annoying.
For portability the general rule is that _if_ you can get away with
using plain 'char', you should.
> This works only as long as you own all of your code. The problem is you can
> assign signed char to unsigned char or vice versa without any ill effects;
> you won't even get a compiler warning. However, the same can't be said for
> signed char * vs unsigned char *. If you are interfacing to external code
> (even functions like strcpy etc), you are asking for a major type casting
> headache. Worse, the problem won't even show up if you are developing on the
> "right" platform. I've gone down that route once and then gave up :-(.
C++ is interesting in that regard, as it treats 'char', 'signed char',
and 'unsigned char' as three different types. If you want to the C
string handling functions, you'll have to use 'char*' for strings, or
implement a workaround.
> Another thing that puzzles me since this whole debate started. If you look
> at the declaration of ctype.h functions (isalpha family), they take a int as
> an argument. The man page explicitly mentions the argument should be an
> unsigned char - obvious because a signed char would sign extend to an int.
> For platforms that default to signed char, and it appears majority of them
> do, you need to cast a "default" char type before calling ctype functions.
> Still, I have not seen any code that does it.
For this reason, implementations of the isalpha family tend to work
around the problem of being given negative-valued char arguments. So
you get code like this in libc's ctype.h:
extern __inline int
tolower (int __c) __THROW
{
return __c >= -128 && __c < 256 ? __ctype_tolower[__c] : __c;
}
As result, faulty code sort-of works, and therefore never gets fixed.
--
Olaf Weber
(This space left blank for technical reasons.)
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > It can't be larger than 255 (precisely because it is limited to a single > byte). > > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. This works only as long as you own all of your code. The problem is you can assign signed char to unsigned char or vice versa without any ill effects; you won't even get a compiler warning. However, the same can't be said for signed char * vs unsigned char *. If you are interfacing to external code (even functions like strcpy etc), you are asking for a major type casting headache. Worse, the problem won't even show up if you are developing on the "right" platform. I've gone down that route once and then gave up :-(. Another thing that puzzles me since this whole debate started. If you look at the declaration of ctype.h functions (isalpha family), they take a int as an argument. The man page explicitly mentions the argument should be an unsigned char - obvious because a signed char would sign extend to an int. For platforms that default to signed char, and it appears majority of them do, you need to cast a "default" char type before calling ctype functions. Still, I have not seen any code that does it. Ganesan
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 31-Dec-01, 16:30 (CST), Peter Finderup Lund <[EMAIL PROTECTED]> wrote: > On 31 Dec 2001, Colin Walters wrote: > > No, the C standard guarantees that a char is exactly a single byte; i.e. > > sizeof(char) == 1. > > I think he meant "wider than one would think"-character. A char didn't > originally have to be 8 bits wide -- the first edition of K & R "The C > Programming Language" explicitly mentions an implementation with 9-bit > chars. > > I think the newer standards say you have to use 8-bit chars but with some > sort of "cat flap" clause that allows exceptions if the platform is a > weird DSP or something like that. Nope, the standard says that 1. sizeof(char) == 1 2. the range of signed char is *at least* -127 -> +127 3. the range of unsigned char is *at least* 0 -> 255 4. "plain" char shall act like one of (2) or (3) The net effect is that chars are *at least* 8 bits wide, but may be wider. The macro "CHAR_BIT" in limits.h will tell if if you really need to know. There is no requirement that char be exactly 8 bits; no cat flap required. Steve
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 31 Dec 2001, Colin Walters wrote: > > and there's a small possibility that char could be some weird wide > > character thing, > > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. I think he meant "wider than one would think"-character. A char didn't originally have to be 8 bits wide -- the first edition of K & R "The C Programming Language" explicitly mentions an implementation with 9-bit chars. I think the newer standards say you have to use 8-bit chars but with some sort of "cat flap" clause that allows exceptions if the platform is a weird DSP or something like that. > It can't be larger than 255 (precisely because it is limited to a single > byte). Careful - a byte is not always the same as an octet. > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. Not when you are using them for characters -- only if you are using them as small integers. Just be very careful when you perform arithmetics and relations on chars. It is often a better idea to use a macro or function from the standard library. -Peter Anxiety, n.: The first time you can't do it a second time. Panic, n.: The second time you can't do it the first time.
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > On Mon, 2001-12-31 at 05:40, Julian Gilbey wrote: > > I believe that the author (Knuth) presumably thought "c should only be > > between 0 and 127, probably not even that far, and we're using c as an > > array index, where we've only allocated 256 chars for this array. > > Right. Then it should be explicitly declared as an "unsigned char". > > > As char might be a signed char, c could feasibly be less than 0, > > Not if you declare it as unsigned explicitly. > > > and there's a small possibility that char could be some weird wide > > character thing, > > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. > > > so c could feasibly be greater than 255, we'll > > perform the checks just check to be on the safe side." Defensive > > programming. > > It can't be larger than 255 (precisely because it is limited to a single > byte). > > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. As someone pointed out, a byte is required to contain at least the unsigned 0 - 255 range. It can be larger. A lot of DSP chips support 32-bit access as the basic element. sizeof(char) == sizeof(long) == 1. Or he could have char redefined in a really stupid and non-C-conforming header somewhere someday. Not his fault. Characters intended to contain character data should in fact be 'char' rather tahn explicitly signed. The C library expects them that way; and the default is chosen for increased performance on the architecture in question, generally, or compatibility. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
I demand that Colin Walters may or may not have written... [snip] > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. Yes, but who's to say that a byte is 8 bits wide? :-) -- | Darren Salt | linux (or ds) at | nr. Ashington, | Linux PC, Risc PC | youmustbejoking | Northumberland | No Wodniws here | demon co uk | Toon Army | http://www.youmustbejoking.demon.co.uk/progs.linux.html#debian> Houdini escaping from New Jersey!
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > On Mon, 2001-12-31 at 05:40, Julian Gilbey wrote: > > I believe that the author (Knuth) presumably thought "c should only be > > between 0 and 127, probably not even that far, and we're using c as an > > array index, where we've only allocated 256 chars for this array. > > Right. Then it should be explicitly declared as an "unsigned char". > > > As char might be a signed char, c could feasibly be less than 0, > > Not if you declare it as unsigned explicitly. > > > and there's a small possibility that char could be some weird wide > > character thing, > > No, the C standard guarantees that a char is exactly a single byte; i.e. > sizeof(char) == 1. OK. So then this check is either unnecessary or guards against the possibility that char is signed and that the chars we've hit are <0. But either way, it's a small piece of defensive programming for an essentially impossible situation. I'm not about to rewrite this code to remove a warning when I will potentially introduce real bugs. > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. That is a wise suggestion, indeed. Although there may be exceptions when it is unnecessary. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, Dec 31, 2001 at 01:33:37PM -0500, Colin Walters wrote: > The more I think about it, the more it makes sense to always explicitly > declare all char variables as signed or unsigned; otherwise, you're just > asking for latent bugs. IMHO, this is a peculiar statement. The type 'char' is best suited to things that are characters or bytes. For array indices, int tends to be a better choice: most CPUs cannot read single bytes any faster than machine words; compilers allocate registers at their full width; some architectures (68K for proper sign extension) sometimes require extra instructions in order to perform sub-word width math; careless alignment can be a problem with sub-word values packed into structures. Obviously, a compelling reason for 'char' as an index is when storing many of them, but in such a care must be taken to write what you mean and declare unsigned-ed-ness when that is what you want. Cheers.
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Mon, 2001-12-31 at 05:40, Julian Gilbey wrote: > I believe that the author (Knuth) presumably thought "c should only be > between 0 and 127, probably not even that far, and we're using c as an > array index, where we've only allocated 256 chars for this array. Right. Then it should be explicitly declared as an "unsigned char". > As char might be a signed char, c could feasibly be less than 0, Not if you declare it as unsigned explicitly. > and there's a small possibility that char could be some weird wide > character thing, No, the C standard guarantees that a char is exactly a single byte; i.e. sizeof(char) == 1. > so c could feasibly be greater than 255, we'll > perform the checks just check to be on the safe side." Defensive > programming. It can't be larger than 255 (precisely because it is limited to a single byte). The more I think about it, the more it makes sense to always explicitly declare all char variables as signed or unsigned; otherwise, you're just asking for latent bugs.
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Sun, Dec 30, 2001 at 11:09:50PM -0500, Colin Walters wrote: > On Sun, 2001-12-30 at 17:02, Julian Gilbey wrote: > > This package is correct as is, and the warning is harmless; the line > > of code involved is: > > > > return (c<0||c>255)? unexpected_char: icode[c]; > > > > where c is a char expected to be in the normal range (0<=c<=127). All > > the chars used in this code (AFAICT) are in this range. > > This still says to me there is likely a logic error in the code; if the > authors thought it was possible for c to take on a negative value at > some point, then it should be declared signed. Otherwise, why not just > declare it unsigned and remove the test for c < 0? I believe that the author (Knuth) presumably thought "c should only be between 0 and 127, probably not even that far, and we're using c as an array index, where we've only allocated 256 chars for this array. As char might be a signed char, c could feasibly be less than 0, and there's a small possibility that char could be some weird wide character thing, so c could feasibly be greater than 255, we'll perform the checks just check to be on the safe side." Defensive programming. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Sun, 2001-12-30 at 17:02, Julian Gilbey wrote: > This package is correct as is, and the warning is harmless; the line > of code involved is: > > return (c<0||c>255)? unexpected_char: icode[c]; > > where c is a char expected to be in the normal range (0<=c<=127). All > the chars used in this code (AFAICT) are in this range. This still says to me there is likely a logic error in the code; if the authors thought it was possible for c to take on a negative value at some point, then it should be declared signed. Otherwise, why not just declare it unsigned and remove the test for c < 0?
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Thu, Dec 27, 2001 at 08:08:51PM +0100, Gerhard Tonn wrote: > [...] > Since in some cases this wrong assumption results in a warning > > comparison is always true due to limited range of data type > or > comparison is always false due to limited range of data type > > I grepped my archived build logs and found that all packages below have got > this problem. Since I have currently not the time to write a bug report for > each I would appreciate if the respective owner could look into the problem. > sgb This package is correct as is, and the warning is harmless; the line of code involved is: return (c<0||c>255)? unexpected_char: icode[c]; where c is a char expected to be in the normal range (0<=c<=127). All the chars used in this code (AFAICT) are in this range. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry Also: http://www.helpthehungry.org/
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
* Joey Hess <[EMAIL PROTECTED]> [20011227 21:24]: > I also notice someone (you?) did a binary NMU of it for s390. Fixing > this problem? AFAIK the binary NMU was done because s390 had toolchain problems at some point. -- Martin Michlmayr [EMAIL PROTECTED]
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Sat, Dec 29, 2001 at 04:52:58PM +0100, Gerhard Tonn wrote: > On Saturday 29 December 2001 11:59, you wrote: > > * Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]: > > > I have changed my mind and will write semi-automatically a bug > > > report for each of the packages with severity grave. > > > > Don't do this. > > That's fine with me. I don't see what it helps though except that the > problems don't appear in the list of release critical bugs. Auto-filing grave bugs is a problem because we're having a hard enough time releasing woody as it is. Alternatively put, arm and powerpc have had this problem for some time, so I'd hope that users of those architectures would have filed bugs about real problems caused by this type of code. -- Colin Watson [EMAIL PROTECTED]
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Sat, Dec 29, 2001 at 11:23:44AM +0100, Gerhard Tonn wrote: > Hi, > I have changed my mind and will write semi-automatically a bug report for > each of the packages with severity grave. > I am currently rebuilding the latest version of each of the packages, so that > a build log for s390 will be available at http://buildd.debian.org/ . I will > then check that the problem is still there and write a bug report considering > those who have already answered me. Please consider the unixodbc problem answered for. I have already filed a bug against this package. Thanks, Steve Langasek postmodern programmer pgpXeIdjJZavY.pgp Description: PGP signature
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Saturday 29 December 2001 11:59, you wrote: > * Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]: > > I have changed my mind and will write semi-automatically a bug > > report for each of the packages with severity grave. > > Don't do this. That's fine with me. I don't see what it helps though except that the problems don't appear in the list of release critical bugs. Gerhard
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Sat, Dec 29, 2001 at 11:59:32AM +0100, Martin Michlmayr wrote: > * Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]: > > I have changed my mind and will write semi-automatically a bug > > report for each of the packages with severity grave. > > Don't do this. There are too many packages involved to file > semi-automatic bugs already and the bugs should not be grave either. > Are you convinced this makes _all_ these packages "unuseable or mostly > so, or causes data loss"? The issue could appear in code which is > actually not relevant for 90% of users (i.e. severity important). > > I suggest you first post a mail desribing this issue to d-d-announce. > Describe exactly why char signedness is a problem and what to do about > it. Show examples how to fix the code (it's not hard but still..). > Then give the developers some time to actually do something about it. > And _then_ _consider_ filing bugs (by discussing it here again). > > -- > Martin Michlmayr > [EMAIL PROTECTED] > I agree. As for yardradius, the bug could be in fact secondary - programs works anyway. Severity level should be evaluated in every single case. -- Francesco P. Lovergine
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
* Gerhard Tonn <[EMAIL PROTECTED]> [20011229 11:23]: > I have changed my mind and will write semi-automatically a bug > report for each of the packages with severity grave. Don't do this. There are too many packages involved to file semi-automatic bugs already and the bugs should not be grave either. Are you convinced this makes _all_ these packages "unuseable or mostly so, or causes data loss"? The issue could appear in code which is actually not relevant for 90% of users (i.e. severity important). I suggest you first post a mail desribing this issue to d-d-announce. Describe exactly why char signedness is a problem and what to do about it. Show examples how to fix the code (it's not hard but still..). Then give the developers some time to actually do something about it. And _then_ _consider_ filing bugs (by discussing it here again). -- Martin Michlmayr [EMAIL PROTECTED]
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Hi, I have changed my mind and will write semi-automatically a bug report for each of the packages with severity grave. I am currently rebuilding the latest version of each of the packages, so that a build log for s390 will be available at http://buildd.debian.org/ . I will then check that the problem is still there and write a bug report considering those who have already answered me. Regards, Gerhard
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Thu, Dec 27, 2001 at 05:20:30PM -0600, Colin Watson wrote: > Perhaps a per-maintainer listing would be helpful here, then: [snip] > Davide Puricelli (evo) <[EMAIL PROTECTED]>: > xchat Version affected by this issue were 1.8.6-1 and 1.8.6-2, 1.8.6-3 comes with a patch that fixes the problem. Best Regards, -- Davide Puricelli, [EMAIL PROTECTED] Debian Developer: [EMAIL PROTECTED] | http://www.debian.org Undergraduate Student of Computer Science at University of Bologna PGP key: finger [EMAIL PROTECTED] pgpkApFnRlUds.pgp Description: PGP signature
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
>> A solution is to declare the datatype explicitly as signed char or compile >> using the option -fsigned-char. >Compiling with -fsigned-char, though it works, is not the "right" >solution. It's better to fix the bug in the code. I agree. As soon as a source is compiled with -fsigned-char and contains a function which calls a function _not_ compiled with -fsigned-char passing a char, this approach doesn't work. Btw., I did the grep on a local copy of the build logs. If you don't find the log of your package at http://buildd.debian.org/ let me know and I will you send an excerpt of the log. Regards, Gerhard
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Thu, Dec 27, 2001 at 08:08:51PM +0100, Gerhard Tonn wrote: > Hi, > I had recently a runtime problem on s390 with a package that compiled fine. > After a while I figured out that it was caused by the fact that the package > owner assumes that a char is signed per default. This is _not_ true on > > arm > powerpc > s390 > > Since in some cases this wrong assumption results in a warning > > comparison is always true due to limited range of data type > or > comparison is always false due to limited range of data type I maintain OpenSLP and also one of the upstream authors. I am looking at the build logs now. Suprisingly, arm build logs doesn't seem to show any compiler warnings though powerpc and s390 build logs do. Any idea why? In any case, I'll fix the problems in the next upload. Ganesan -- Ganesan R <[EMAIL PROTECTED]>
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Gerhard Tonn wrote: > The build logs can be found at http://buildd.debian.org/ . > xgalaga Oddly enough I can't find any build logs for xgalaga on buildd.debian.org, although it has built for many arches. Where's the build log? I also notice someone (you?) did a binary NMU of it for s390. Fixing this problem? -- see shy jo
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Thu, Dec 27, 2001 at 08:08:51PM +0100, Gerhard Tonn wrote: > I grepped my archived build logs and found that all packages below have got > this problem. Since I have currently not the time to write a bug report for > each I would appreciate if the respective owner could look into the problem. Perhaps a per-maintainer listing would be helpful here, then: A Mennucc1 <[EMAIL PROTECTED]>: lpr-ppd snmpkit Aaron Lehmann <[EMAIL PROTECTED]>: abiword koules Adam Lazur <[EMAIL PROTECTED]>: rats Adrian Bridgett <[EMAIL PROTECTED]>: xmove Adrian Bunk <[EMAIL PROTECTED]>: mdk recover tmview Aigars Mahinovs <[EMAIL PROTECTED]>: re Alain Schroeder <[EMAIL PROTECTED]>: viewml Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>: fwlogwatch Andreas Tille <[EMAIL PROTECTED]>: paul Anthony Fok <[EMAIL PROTECTED]>: xcin2.3 xcingb Anthony Wong <[EMAIL PROTECTED]>: lpkg Anton Zinoviev <[EMAIL PROTECTED]>: cbedic Antti-Juhani Kaijanaho <[EMAIL PROTECTED]>: catdvi Arthur Korn <[EMAIL PROTECTED]>: nail Ashley Clark <[EMAIL PROTECTED]>: bottlerocket Atsuhito KOHDA <[EMAIL PROTECTED]>: e2ps Aubin Paul <[EMAIL PROTECTED]>: scite Barak Pearlmutter <[EMAIL PROTECTED]>: camserv Baruch Even <[EMAIL PROTECTED]>: pfaedit template-new Bas Zoetekouw <[EMAIL PROTECTED]>: freesci xpenguins xpenguins-applet Bastian Blank <[EMAIL PROTECTED]>: berlin Ben Armstrong <[EMAIL PROTECTED]>: snowflake Ben Collins <[EMAIL PROTECTED]>: glibc Ben Gertzfield <[EMAIL PROTECTED]>: gimp1.2 Bradley Marshall <[EMAIL PROTECTED]>: gnokii Brian Mays <[EMAIL PROTECTED]>: gnugo-dv Brian Russo <[EMAIL PROTECTED]>: knapster2 Carlos Prados <[EMAIL PROTECTED]>: eco5000 Chad Walstrom <[EMAIL PROTECTED]>: pnm2ppa Chip Salzenberg <[EMAIL PROTECTED]>: nfs-utils Chris Hanson <[EMAIL PROTECTED]>: uudeview Chris Ruffin <[EMAIL PROTECTED]>: electric Chris Waters <[EMAIL PROTECTED]>: gxedit Christian Leutloff <[EMAIL PROTECTED]>: gdl Christian Meder <[EMAIL PROTECTED]>: lclint Christian Perrier <[EMAIL PROTECTED]>: lifelines Colin Watson <[EMAIL PROTECTED]>: denemo Craig Small <[EMAIL PROTECTED]>: mnogosearch Dale Scheetz (Dwarf #1) <[EMAIL PROTECTED]>: spider Dan Nguyen <[EMAIL PROTECTED]>: netspades Daniel Burrows <[EMAIL PROTECTED]>: xarchon Daniel Burrows <[EMAIL PROTECTED]>: lbreakout lbreakout2 Daniel Glassey <[EMAIL PROTECTED]>: sword Daniel Martin <[EMAIL PROTECTED]>: fvwm95 tkdesk Daniel Schepler <[EMAIL PROTECTED]>: xzip David Frey <[EMAIL PROTECTED]>: spell uutraf David Huggins-Daines <[EMAIL PROTECTED]>: sphinx2 t1lib David Z Maze <[EMAIL PROTECTED]>: xcircuit Davide Puricelli (evo) <[EMAIL PROTECTED]>: xchat Debian QA Group <[EMAIL PROTECTED]>: ilu leksbot mh Debian QA Team <[EMAIL PROTECTED]>: dstooltk Dennis Schoen <[EMAIL PROTECTED]>: ntop Dirk Eddelbuettel <[EMAIL PROTECTED]>: octave2.1 Domenico Andreoli <[EMAIL PROTECTED]>: curl-ssl Douglas Bates <[EMAIL PROTECTED]>: xlispstat Ed Boraas <[EMAIL PROTECTED]>: libflux0 Eduardo Marcel Macan <[EMAIL PROTECTED]>: clara Enrique Zanardi <[EMAIL PROTECTED]>: newt Eric Van Buggenhaut <[EMAIL PROTECTED]>: iiwusynth Fernando Sanchez <[EMAIL PROTECTED]>: mrt qcad sablotron Filip Van Raemdonck <[EMAIL PROTECTED]>: clanlib0 gtkcookie Francesco Paolo Lovergine <[EMAIL PROTECTED]>: yardradius Frank Kirschner <[EMAIL PROTECTED]>: ldmud Frederic Peters <[EMAIL PROTECTED]>: ethereal Fumitoshi UKAI <[EMAIL PROTECTED]>: skkinput Ganesan Rajagopal <[EMAIL PROTECTED]>: openslp Gerd Knorr <[EMAIL PROTECTED]>: motv openmotif xawtv Gerfried Fuchs <[EMAIL PROTECTED]>: francine rungetty Gerrit Pape <[EMAIL PROTECTED]>: log2mail Glenn McGrath <[EMAIL PROTECTED]>: dact Gopal Narayanan <[EMAIL PROTECTED]>: yacas Graeme Mathieson <[EMAIL PROTECTED]>: libconvert-uulib-perl Guillaume Morin <[EMAIL PROTECTED]>: vpnd xerces Gustavo Noronha Silva <[EMAIL PROTECTED]>: penguineyes si Guus Sliepen <[EMAIL PROTECTED]>: crawl omega-rpg Hamish Moffatt <[EMAIL PROTECTED]>: aprsdigi gerbv phaseshift xastir Hector Garcia <[EMAIL PROTECTED]>: zmailer zmailer-ssl Henrique de Moraes Holschuh <[EMAIL PROTECTED]>: fcron Herbert Xu <[EMAIL PROTECTED]>: lesstif1-1 rstatd Hugo van der Merwe <[EMAIL PROTECTED]>: oregano Ian Lynagh <[EMAIL PROTECTED]>: libgtop Ingo Saitz <[EMAIL PROTECTED]>: songprint Ivo Timmermans <[EMAIL PROTECTED]>: libsidplay James LewisMoss <[EMAIL PROTECTED]>: gnome-admin Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>: sac Jerome Marant <[EMAIL PROTECTED]>: giram icewm python-4suite Jochen Voss <[EMAIL PROTECTED]>: gnome-utils Joey Hess <[EMAIL PROTECTED]>: xgalaga Jonathan Hseu <[EMAIL PROTECTED]>: falconseye Jonathon D Nelson <[EMAIL PROTECTED]>: afterstep Joost van Baal <[EMAIL PROTECTED]>: blackened Jordi Ma
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Thu, Dec 27, 2001 at 02:37:33PM -0500, Colin Walters wrote: > On Thu, 2001-12-27 at 14:08, Gerhard Tonn wrote: > > A solution is to declare the datatype explicitly as signed char or compile > > using the option -fsigned-char. > > Compiling with -fsigned-char, though it works, is not the "right" > solution. It's better to fix the bug in the code. > Right, eg yardradius incorrectly assumes that getopt() returns a char instead of an int (grunt!). So, that warning could be the symptom of another kind of error, as in that case. I'll complain with my upstream tomorrow morning for this, when I'll see him... in the bath, in front to the mirror :( -- Francesco P. Lovergine
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On Thu, 2001-12-27 at 14:08, Gerhard Tonn wrote: > A solution is to declare the datatype explicitly as signed char or compile > using the option -fsigned-char. Compiling with -fsigned-char, though it works, is not the "right" solution. It's better to fix the bug in the code.
at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
Hi, I had recently a runtime problem on s390 with a package that compiled fine. After a while I figured out that it was caused by the fact that the package owner assumes that a char is signed per default. This is _not_ true on arm powerpc s390 Since in some cases this wrong assumption results in a warning comparison is always true due to limited range of data type or comparison is always false due to limited range of data type I grepped my archived build logs and found that all packages below have got this problem. Since I have currently not the time to write a bug report for each I would appreciate if the respective owner could look into the problem. A solution is to declare the datatype explicitly as signed char or compile using the option -fsigned-char. The build logs can be found at http://buildd.debian.org/ . Thanks, Gerhard abiword aee afterstep amaya anjuta appindex aprsdigi apt-spy asclassic asd4 autoclass ava aview beav berlin bl blackened blinkd bnetd bottlerocket c2050 camserv catdoc catdvi cbedic cern-httpd chimera2 cim cint clanlib0 clara console-tools crawl crimson curl-ssl dact dbview denemo dopewars dotconf dstooltk dx e2ps eco5000 ee electric elvis eterm ethereal everybuddy-cvs everybuddy evolution exdbm exult falconseye fcron flek flightgear flin francine freeamp freesci ftpgrab fvwm95 fwlogwatch gdl genesis genparse gerbv gimp1.2 giram glibc gliv gnapster gnokii gnome-admin gnome-chess gnome-pilot-conduits gnome-utils gnugo-dv gnumeric gom gphoto2 gpm grace gtetrinet gtkcookie gtkhx gxedit hanzim hextype icewm id3ren iiwusynth ilu imlib2 imwheel jmon kdelibs knapster2 koules lbreakout2 lbreakout lclint ldmud le ledcontrol leksbot lesstif1-1 libconvert-uulib-perl libflux0 libgtop libsidplay libtrain lifelines liveice log2mail lout lpkg lpr-ppd mailleds malsync marbles marlais mdk metamail mgetty mh micq mnogosearch motv mp3rename mrt mscompress nail ncbi-tools6 ncpfs netdiag netspades newt nfs-utils ntop nullmailer octave2.1 omega-rpg openh323 openmotif opennap openslp oregano orville-write osdclock p2c partimage paul pdnsd penguineyes perl-tk pfaedit pftp phaseshift pike7-crypto pike7.2 pike7 pnm2ppa pptpd prips python-4suite qcad rats re recover rstatd rungetty s3mod sablotron sac scite sclient scribus sgb shapetools si sigrot sitecopy skkinput snmpkit snowflake songprint spell sphinx2 spider startalk sted2 sword t1lib taper tcpstat tct template-new tkdesk tmview transformiix uisp unhtml unicon unixodbc uudeview uutraf vcdimager vcg vflib3 vfu viewml vlad vpnd vrflash w3c-libwww webalizer wmaker wmppxp workbone worklog wxwindows2.2 x11iraf xarchon xastir xawtv xchat xcin2.3 xcingb xcircuit xdrawchem xerces xfce xgalaga xlispstat xlockmore xlogmaster xmille xmms xmove xpaint xpenguins-applet xpenguins xsane xscavenger xshipwars xzip yacas yardradius yorick zmailer-ssl zmailer
