mckeeman@wivax.UUCP (04/30/84)
I am sad to see so many human cycles going into the task of deciphering the C bible, and confessions that "maybe I did not read it right". The state of the definition of c is cause to refuse to use it. To be constructive, I have a c-lexicon derived from the MetaWare lexical analyzer that formally answers all these nit-picky questions in a couple of pages. Now, unfortunately, my students and I could not bear to let 019 stand for 17 decimal (and other hacks). So it really isn't c. Is it worth the effort to publish this? Or is there already one out there I have missed? /s/ Bill McKeeman ...decvax!wivax!mckeeman
dyer@wivax.UUCP (Stephen Dyer) (05/01/84)
019 being equal to 17 decimal is an attribute of the VAX PCC lexer; it is not a part of the C language definition. Without disregarding the many baroque qualities of the language definition, one must realize that 'net.lang.c' is a newsgroup for Talmudic dissection of Kernighan and Ritchie--weird questions are expected. ANSI C should help clarify some of the ambiguities. God help us when net.lang.ada really begins to be used! -- /Steve Dyer decvax!bbncca!sdyer sdyer@bbncca
mckeeman@wivax.UUCP (05/01/84)
Thanks for making my point for me Steve. This newsgroup may well be for Talmudic ruminations in which case someone ought to invite me off. However, 019=17 is not a property of VAX C; it is kosher. According to the scripture, section 2.4.1, "the digits 8 and 9 have octal value 10 and 11 respectively". This is at the end of a chain that starts in section 2.3 where "int and float constants have already been disposed of,..." which apparently refers to the material in section 1.2 which, to my most careful reading never mentions the form of int constants (only the machine representations of their values). I did have some hope that section 18.1 where constant shows up in the syntax might help; alas it is undefined. Thus my complaint about the quality of the definition of C. Index or no, I should not have to munge around to find out such details. /s/ Bill McKeeman
gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/02/84)
Since by your own admission your lexicon is not C, it is hard to see what use it would be. Also, where did you get the correct definitions? I thought the standardization effort was still underway...
brownell@harvard.UUCP (Dave Brownell) (05/03/84)
An interesting side note to the 019 discussion -- in "User Level
Changes to the C Language", published with the System V Transition
Aids, octal digits 8 and 9 are retracted. Compilers now give warnings,
and treat them as 010 and 011. "Future releases will make such
usage a fatal error."
This is the only official word I know of from Bell Labs since the 1980
edition of the C Reference manual. It also includes enumerations,
structure and union assignments, nonunique structure names, complete
structure qualification required, 'void' type, "long x 1;" initializations
are gone, "x=+5" gone (whee), and bug fixes.
There's more implied equality of C and PCC, which is fine from Bell's
point of view but less so for other compiler writers.
Dave Brownell
{decvax!genrad, allegra!wjh12, ihnp4!harvard} !sequoia!brownelleich@uiuccsb.UUCP (05/05/84)
#R:wivax:-1945700:uiuccsb:9000025:000:425 uiuccsb!eich May 4 18:32:00 1984 Reference Manual, 2.4.1 (p180) An integer constant consisting of a sequence of digits is taken to be octal if it begins with 0 (digit zero), decimal otherwise. The digits 8 and 9 have octal value 10 and 11 respectively. So this isn't a PCC lapse. And what's wrong with it? The alternatives are either to treat the number as decimal or to flag an error. Neither seems better to me. Brendan Eich uiucdcs!uiuccsb!eich
dyer@wivax.UUCP (Stephen Dyer) (05/06/84)
Oh, my, it is certainly a good idea to flag the digits 8 and 9 as an error in an octal number. I can't imagine any code where this would be other than unintentional, and if it's NOT then it's worth rewriting the constant so that it's better understood by those who will have to maintain it. The new System V spec which eliminates this as a valid C construct is only to the good, and in fact agrees with the behavior of many non-PCC and non-Ritchie compilers. -- /Steve Dyer decvax!bbncca!sdyer sdyer@bbncca
guido@mcvax.UUCP (Guido van Rossum) (05/07/84)
[I can't resist...] There is ONE case where it is ridiculous to flag the digits 8 or 9 as an error in an octal contant: when there are no other digits. So I'd still be able to use 08 and 09 (e.g. in an aligned list like 01 02 03 04 05 06 07 08 09 10 11 ...).
mats@dual.UUCP (Mats Wichmann) (05/07/84)
Seems to me this has been discussed before (perhaps another group?
or am I just confused).
I remember hearing that 08 and 09 are now flagged as warnings by the
latest C compilers, and in the future will not work at all.
Mats Wichmann
Dual Systems Corp.
...{ucbvax,amd70,ihnp4,cbosgd,decwrl,fortune}!dual!mats
It now became apparent (despite the lack of library paste)
that something had happened to the vicar; [ Edward Gorey ]liberte@uiucdcs.UUCP (05/08/84)
#R:wivax:-1945700:uiucdcs:27600033:000:443 uiucdcs!liberte May 8 13:47:00 1984 I am also disturbed by the use of 8 an 9 in octal numbers. It is an error to use them and it is an error to allow them. I fixed it in our 4.2 awk. Thought you might appreciate this proof that all odd numbers are prime: /**** uiucdcs:net.jokes / cygnet!kwd / 2:27 am May 4, 1984 ****/ C Hacker's Proof: 03 is prime, 05 is prime, 07 is prime, ... 09 is really 11, which as everyone knows is prime... /* ---------- */ Daniel LaLiberte