mvz@tove.UUCP (Marvin V. Zelkowitz) (01/18/85)
Does anyone have access to an LALR grammar for C? Does one exist? Reply to mvz@maryland.
MLY.G.SHADES%MIT-OZ@MIT-MC.ARPA (01/21/85)
in response to marvin v. zelkowitz's request for a lalr
grammar for c i recommend:
"c a reference manual"
by samuel p. harbison
and guy l. steele jr.
of tartan laboratories
prentice-hall 1984
$19.95
not only does this book provide both a rigorous and non-rigourous
definition for c but it also talks about side issues and
implementation problems/features/bugs. in my opinion a must book for
anyone trying to develop a c compiler.
shades@mit-oz.arpaaeb@turing.UUCP (02/12/85)
Having the personality of a kumquat and wanting to befuddle my friends
I cranked some of my C programs through the recently posted parser.
Unfortunately it complained about correct fragments like
...
if ((*buf == ':') || (('a' <= *buf) && ('z' >= *buf)))
...
because it parsed all of ':') || ..... ('z' as one single character constant.
Also the handling of backslashes in strings was not quite correct.
The diff below shows how one might change scan.l in order to improve
the parser's behaviour. I am not sure about the + . Are multi-character
character constants permitted by the new standard? (I hope not.)
*** scan.l.orig Tue Feb 12 11:38:07 1985
--- scan.l Tue Feb 12 17:16:09 1985
***************
*** 56,62
0{D}+{US}?{LS}? { count(); return(CONSTANT); }
{D}+{LS}?{US}? { count(); return(CONSTANT); }
{D}+{US}?{LS}? { count(); return(CONSTANT); }
! '.*' { count(); return(CONSTANT); }
{D}+{E}{LS}? { count(); return(CONSTANT); }
{D}*"."{D}+({E})?{LS}? { count(); return(CONSTANT); }
--- 56,62 -----
0{D}+{US}?{LS}? { count(); return(CONSTANT); }
{D}+{LS}?{US}? { count(); return(CONSTANT); }
{D}+{US}?{LS}? { count(); return(CONSTANT); }
! '(\\.|[^\\'])+' { count(); return(CONSTANT); }
{D}+{E}{LS}? { count(); return(CONSTANT); }
{D}*"."{D}+({E})?{LS}? { count(); return(CONSTANT); }
***************
*** 62,68
{D}*"."{D}+({E})?{LS}? { count(); return(CONSTANT); }
{D}+"."{D}*({E})?{LS}? { count(); return(CONSTANT); }
! \"(\\\"|[^"])*\" { count(); return(STRING_LITERAL); }
">>=" { count(); return(RIGHT_ASSIGN); }
"<<=" { count(); return(LEFT_ASSIGN); }
--- 62,68 -----
{D}*"."{D}+({E})?{LS}? { count(); return(CONSTANT); }
{D}+"."{D}*({E})?{LS}? { count(); return(CONSTANT); }
! \"(\\.|[^\\"])*\" { count(); return(STRING_LITERAL); }
">>=" { count(); return(RIGHT_ASSIGN); }
"<<=" { count(); return(LEFT_ASSIGN); }
--
Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aebjeff@gatech.UUCP (Jeff Lee) (02/19/85)
> The diff below shows how one might change scan.l in order to improve > the parser's behaviour. I am not sure about the + . Are multi-character > character constants permitted by the new standard? (I hope not.) Yes. In the new standard, multicharacter character constants are allowed but (of course) are implementation defined. A character constant is an INT so you can guess what most implementations will do. -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff.GATech @ CSNet-Relay uucp: ...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff
henry@utzoo.UUCP (Henry Spencer) (02/21/85)
> Yes. In the new standard, multicharacter character constants are allowed > but (of course) are implementation defined. A character constant is an INT > so you can guess what most implementations will do. Already do, you mean. There's nothing new about multi-character character constants; they've been in C all along, with the same warnings about them being highly implementation-dependent. I'm a bit disappointed that the ANSI committee didn't delete them. Oh well. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jeff@gatech.UUCP (Jeff Lee) (03/01/85)
> > Yes. In the new standard, multicharacter character constants are allowed > > but (of course) are implementation defined. A character constant is an INT > > so you can guess what most implementations will do. > > Already do, you mean. There's nothing new about multi-character character > constants; they've been in C all along, with the same warnings about them > being highly implementation-dependent. I'm a bit disappointed that the > ANSI committee didn't delete them. Oh well. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Yes, I should have made that clearer. The correct phrase should probably have been "the new standard is continuing to propogate multi-character character constants". I don't understand leaving something that machine dependant in it, but at the same time they are removing one of the more useful additions; the CASE range. The last draft allowed a case to contain a "const .. const" contruct but (according to the draft that came here just today) that has now been removed. The notes say that it was removed after some discussion but what discussion was not mentioned. Oh well.... -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff.GATech @ CSNet-Relay uucp: ...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff
schwrtze@acf8.UUCP (E. Schwartz group) (12/18/85)
A while back someone I believe posted one. Please could someone drop me a note saying they have it to give and I will select one person to send it. Thanks. Hedley Rainnie hedley@alaya cmcl2!alaya!hedley ps: It is needed for GNU emacs as a quick syntax checker. I will post the completed checker of course.
hitchins@gec-mi-at.co.uk (Andy Hitchins) (09/10/86)
Has anyone got a copy of the 'C' grammar (ansi C if possible) in a form suitable for top down parsing. (Recursive Decent). Thanks in advance Andy Hitchins ***************************************************************************** ** Marconi Instruments Ltd ** UUCP : ...mcvax!ukc!hrc63!miduet!hitchins ** ** St. Albans AL4 0JN ** NRS : hitchins@uk.co.gec-mi-at ** ** Herts. UK ** ** ***************************************************************************** ** "The views expressed herein do not necessarily reflect" ** ** "those of my employer, and may not even reflect my own" ** ***************************************************************************** ** Andy Hitchins ** Phone: 44 727 59292 x202 ** *****************************************************************************