Re: C syntax errors

Every so often a detailed reply such as this comes along, explaining an 
excruciatingly difficult concept with such breathtaking clarity, with 
such depth of vision and knowledge of history and realization dawns: I 
stand amongst GIANTS !

Thank you for all the insights that you share so freely.

Respectfully,
Pillai

On 01/18/2014 03:08 PM, Mark S Waterbury wrote:
> Hi, again, Frank:
>
> Setting aside the apparent "bad examples" on that web site ...
>
> Responding to your original questions about how to read and understand C
> syntax, the following might help you to comprehend it better.
>
> When Dennis Ritchie first designed C, it was not meant to be a "general
> purpose" programming language for all sorts of applications; it was
> meant as a "systems programming language' for use in developing the Unix
> operating system.   As such, it was intended to be much closer to a
> traditional "assembler language" than most other higher-level
> languages.  Like most assemblers, this included the idea of a "macro
> processor" to make certain coding tasks easier.
>
> Since it was not meant for a general audience, but was intended
> originally for their own use internally within Bell Labs, they did not
> have the goals of making it easy to read or understand for ordinary
> mortals. They wanted to create a concise notation that would be easy for
> the C compiler to parse and "understand".   Much of the terseness of C,
> such as the use of special characters like "{" and "}" instead of more
> traditional "begin" and "end" keywords was due to the equipment used at
> that time -- in the late '60s and early '70, they were using actual
> teletypes and similar low-speed terminals to interact with these
> minicomputers.  So, the goal was to reduce the number of keystrokes
> needed to represent a given statement.
>
> All of the early C compilers written by Dennis Ritchie were developed
> using "top-down, recursive descent" parsing techniques. This in part
> influenced the language design (syntax) and those early compilers gave
> reasonable "readable" syntax errors.  With Unix Version 7, for greater
> "portability," AT&T switched over to the new "Portable C Compiler" (PCC)
> developed using YACC and LEX (compiler writing tools). YACC is a
> "bottom-up" LALR parser generator. LALR table-driven parsers and the
> grammars they accept are notorious for generating syntax errors that
> often "make no sense" to humans looking at the compiler generated source
> listing.
>
> How to read C declarations
> =====================
> With the C language, "declarations" are probably the most difficult part
> of the language to comprehend (for most people).  A long time ago, I
> learned this heuristic ("trick") to aid in understanding C
> declarations:  Read them "from the middle out." What do I mean by this?
>
> Consider the following snippet of C code:
>
>       int    a[10];
>
> First, we find the "middle" -- the name of what is being declared, in
> this case, "a" -- then we look to the right and see that it is an array,
> as denoted by the presence of square brackets, and we see it is defined
> with 10 elements.  Then, from the "a", we look to the left to see that
> this is an array of integers.
>
> Now, consider the following:
>
>       char    *c;
>
> First, we find that "c" is what is being declared; next, we look to the
> right -- nothing there -- so looking to the left, we see that "c" is a
> pointer to character(s).      (Note that in C, a character string is
> represented by a pointer to the first character, and the "string" is
> terminated by a "null" character, x'00').
>
> Next, consider:
>
>       char    name[10] = "Waterbury";
>
> This declares name to be a 10 character array initialized to the string
> "Waterbury" (C automatically adds the null x'00' character to the end).
>
> Note that in early K&R C, this could also be declared as:
>
>       char    *name = "Waterbury";
>
> There is intentional ambiguity between arrays and pointers. The name of
> the array denotes the address of the first position of the array.  These
> ambiguities were chosen intentionally, to provide the same kind of
> low-level flexibility available to assembler language programmers of
> that day, and to try to allow programmers to squeeze as much performance
> out of the computers of that day as possible.  So, the following
> statement could be used to print the value of name:
>
>       printf(name);
>
> with either definition of name.
>
> Now, consider:
>
>       char *name[10];
>
> Here, we find "name" to be an array of 10 elements each of which
> contains a pointer to characters.
>
> One more example:
>
>       char    *month[] = { "January", "February", "March", "April",
> "May", "June",
>                   "July", "August", "September", "October", "November",
> "December"};
>
> Here, we have an array named "month" of pointers to characters, and the
> array elements are initialized (as seen to the right of the "="). So,
> this defines an array of 12 elements, each initialized to the name of
> each month, e.g. month[3] = "March".
>
> I hope this helps a little ...
>
> All the best,
>
> Mark S. Waterbury
>
>   > On 1/17/2014 5:38 PM, frank kolmann wrote:
>> I am new to C.
>>
>> Given that C compilers throw up Syntax errors at seemingly random places,
>> how do experienced programmers cope?
>> Any advice will be most welcome.
>> -rant on-
>> To me C is the antithesis of the KISS principal.  Given the convolutions
>> possible in C code I wonder how are any C programs written at all.
>> It seems that you need an ability to decompile C code in your head. The
>> forwards and backwards nature of deciphering a C definition is so arcane
>> that the only reason I can think why anyone would have designed such a
>> language is to show 'look at me, arnt I clever'.
>> C macro substitution seems to be a disaster waiting to happen. Who is
>> clever enough to construct a macro that can accept arbitrary input and yet
>> produce reliable results.
>> -rant off-
>> I fact I am trying to compile a bit of C code I found on the net  that
>> attempts to translate C constructs into words but it fails on the iSeries
>> with a syntax error.
>> Presumable it has compiled elsewhere.
>> http://www.c-program-example.com/2012/02/k-r-c-programs-exercise-5-20.html
>>
>> I though I was a programmer, I know Basic Fortran Cobol RPG(all variants)
>> but I realise now that I am just a mere dabbler and there exist super
>> beings with mystical abilities akin to sorcerers who program in C.
>>
>> Frank Kolmann

-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.