Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 16 Mar 2012 23:24:44 -0500 Message-ID: <4F642018.7584@mindspring.com> Date: Sat, 17 Mar 2012 00:24:40 -0500 From: pete Reply-To: pfiland@mindspring.com Organization: PF X-Mailer: Mozilla 3.04Gold (WinNT; I) MIME-Version: 1.0 Newsgroups: comp.lang.c Subject: Re: A very simple parser with scanf & C References: <88940b22-00a2-4d6e-81e1-51214b073a96@fe21g2000vbb.googlegroups.com> <0.f62ca533fe3fac1321b9.20110924024253BST.87zkhuu34y.fsf@bsb.me.uk> <0.4c392657a43f99297620.20110924144538BST.87fwjmt5od.fsf@bsb.me.uk> <0.a5ee7a90b39e01baef80.20110924222135BST.87litdskkg.fsf@bsb.me.uk> <87d3eoy3p8.fsf@bazspaz.fatphil.org> <4F202866.5BEA@mindspring.com> <4F28C3E1.2C41@mindspring.com> <4F5BB70E.84B@mindspring.com> <4F613025.6244@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 96 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 4.154.222.202 X-Trace: sv3-mnZFfQ6siiU7w1U7y3L2abufUMFtmZv1BYNp+Wdwn+2dGm/n06xCS0MXa4t02ju2E1j9yCq8ZRoGxdA!9alx53vbhGUajS+PgKJfiqzYGqZuYQ3laMETuIIGoGM6lVEQnsXl8GHQ6e/Ck4YwGAg8xTE3jGdO!Fs+z22T+iE0= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5429 Xref: csiph.com comp.lang.c:18830 Tim Rentsch wrote: > > pete writes: > > > Tim Rentsch wrote: > >> > >> pete writes: > >> > >> > Tim Rentsch wrote: > >> >> > >> >> pete writes: > >> >> > >> >> > Tim Rentsch wrote: > >> >> >> > >> >> >> pete writes: > >> >> >> > >> >> >> > Tim Rentsch wrote: > >> >> >> > > >> >> >> >> [snip] > >> >> > > >> >> > If you're going to say for {char c;} > >> >> > > >> >> >>> isalpha( * (unsigned char*) &c ) > >> >> >>> > >> >> >>> rather than > >> >> >>> > >> >> >>> isalpha( (unsigned char ) c ) > >> >> > > >> >> > then I think we should consider a case where > >> >> > ( * (unsigned char*) &c ) > >> >> > is different from > >> >> > ( (unsigned char ) c ) > >> >> > and the only case I can think of, > >> >> > is where (c) is signed, negative and not twos complement. > >> >> > >> >> Right (ignoring padding bits in char, which no sane > >> >> implementation has), although actually there is one other > >> >> case, namely a two's complement trap representation. Not > >> >> very likely perhaps but it is allowed, so for the sake of > >> >> completeness I think it should be mentioned. (And now it > >> >> has been...) > >> > > >> > Considering that file operations are at the root of this thread: > >> > > >> > If char is signed, and char c is assigned a value of (-1), as in > >> > char c; > >> > c = -1; > >> > > >> > and if (c) is written to a file using fputc, > >> > then the value written into the file will be ((unsigned char)-1). > >> > > >> > If that same byte is read back from the same file using fgetc, > >> > then the value returned by fgetc will be > >> > ((int)(unsigned char)-1) > >> > which is equal to ((unsigned char)c) > >> > regardless of the representation of negative integers. > >> > > >> > The return value of fgetc will be unequal to > >> > ( * (unsigned char*) &c ) > >> > when negative integers are either sign and magnitude > >> > or one's complement. > >> > >> That's right, of course. Which form should be used depends > >> on where the bytes came from in the first place -- if they > >> had been written with fwrite(), for example, then the type > >> punning form, rather than the ordinary converting form, is > >> probably a better choice. And conversely. > >> > >> I suspect this is all a moot point anyway, since the values > >> that might be affected most likely will all have the same > >> characteristics vis-a-vis the functions. So I > >> will just say thank you for an interesting discussion. > > > > As far as the ctype functions go, > > if you want use isalpha to give you some idea of > > whether or not putchar(c) is going to output an alpha, > > then isalpha((unsigned char)c) is the way to do it, > > because the value returned by putchar(c) > > compares equal to ((unsigned char)c). > > I don't find this argument persuasive, because in essence it's > no more than the tautology that 'isalpha( (unsigned char) c )' > is equal to 'isalpha( (unsigned char) c )'. It is just as true > that 'isalpha( *(unsigned char*) &c )' will be equal to > 'isalpha( *(unsigned char*) &c )' (and similarly for putting > the value through the fputc()/fget() step). That doesn't prove > anything. isalpha((unsigned char)c) will tell you if the output of putchar(c) is an alpha because putchar(c) is equal to putchar((unsigned char)c). -- pete