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