Re: C syntax errors

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.