2011/12/2 Joerg Sonnenberger <jo...@britannica.bec.de>: > On Fri, Dec 02, 2011 at 07:33:15PM -0200, Iván Briano (Sachiel) wrote: >> 2011/12/2 Joerg Sonnenberger <jo...@britannica.bec.de>: >> > On Fri, Dec 02, 2011 at 10:16:17PM +0100, Vincent Torri wrote: >> >> so why not just do a & 0xff instead of casting ? >> > >> > The cast is IMO cleaner in the intentions. It also has the theoretical >> > advantage of working independent of CHAR_BIT==8. >> > >> >> We are not reading from a file so there' won't really be an EOF, but I insist >> on it. How does isspace() recognize EOF when you are casting to unsigned >> char? >> Even if we don't need it now, it makes the whole deal smell to a nasty >> hack covering >> from some obscure bug. And if there's no bug, then what are fixing here? > > The input is a character stream. If you are storing EOF inside char *, > you have already done something wrong. That's why e.g. fgetc() returns > an int, so that you can distinguish them. > > The problem here is that (char)-128 is sign extended to (int)-128, which is > quite different from (int)(unsigned char)-128, which is 0x80. A perfectly > valid implementation of the ctype.h "functions" is > > #define isspace(x) (typetable[(x) + 1] & TYPE_SPACE) > > Without the cast, this can access memory before the start of the table. > Some systems apply work arounds to let broken code pass. On Linux, it > duplicates the upper half of the table below and uses 128 as offset. > This doesn't penalize correct code, but implies incorrect results for > 8bit clean locales. On OpenBSD, it internally compares to EOF (aka -1) > and returns 0 explicitly. Same problem with the additional cost of a > compare on platforms without unsigned char by default. > > What it all boils down to is that certain parts of the C standard > libraries are interacting badly with platforms where char is signed. > That's not something that can fixed easily. > > On the positive side, a macro definition like the above ensures that > many compilers will warn about the incorrect instances. >
Wonderful! Now we have an actual explanation of why the patch is needed instead of just discussing the interpretation of a man page. Thanks a lot. > Joerg > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
