Comments requested: brief summary of C

[Adam Barr]

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

If anyone is interested, please feel free to read it and send me
comments. Note that the material is copyrighted, this document is
provided for review only, and the ideas contained in any comments may
be used in the book, in whole or in part, with no rights granted to
the person who provided the comments. I will however acknowledge by
name (if desired) anyone who sends comments.

The information is in PDF form per my publisher's request, but if this
is a problem for anyone, email me and I can send it to you in plain
text.

The file is at

http://www.proudlyserving.com/language/c.pdf

I have written similar summaries for other languages and have or will
post them in the appropriate newsgroups.

Thank you.

- Adam Barr
ad****@gte.net

[Richard Heathfield]

Adam Barr wrote:

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

It isn't.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[j]

"Adam Barr" <ad****@gte.net> wrote in message
news:ce**************************@posting.google.c om...

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

If anyone is interested, please feel free to read it and send me
comments. Note that the material is copyrighted, this document is
provided for review only, and the ideas contained in any comments may
be used in the book, in whole or in part, with no rights granted to
the person who provided the comments. I will however acknowledge by
name (if desired) anyone who sends comments.

The information is in PDF form per my publisher's request, but if this
is a problem for anyone, email me and I can send it to you in plain
text.

The file is at

http://www.proudlyserving.com/language/c.pdf

``Statements in C end with a semi-colon ( ; ).''

No, not true. By that definition the following
qualifies as a statement:

int foo;

A declaration is _not_ a statement. Read 6.8 of c99.
``C treats all blanks space as equivalent, so line breaks
and indents are for readability only.''

So #define FOO 10
is the same as #defineFOO10 ?
``A single statement without the braces also counts as a
block of code.''

No, it counts as a single statement.
``A char holds a single byte. Single characters are
surrounded by single quotes, such as 'a' and 'x' .''

I think you should also mention that char is an integer type
and the character literals are of type int. Otherwise
your statement can be misleading.
``Strings are simply arrays of type char. By convention,
a string is terminated with a 0 value, written as a single
character '\0' .''

Not adequate enough. As the standard says:
``A string is a contiguous sequence of characters terminated
by and including the first null character.''
``(you could put a different character in the tenth byte,
but it would then not be a properly-terminated string
according to C conventions).''

It would not be a string whatsoever if there is no
null character.
``char pointers are often assigned to constant strings, for example
city = "Boston";

It is not assigned to ``constant'' strings(you should call it a string
literal). It is assigned the address that the string literal decays to.
``Pointers are also dereferenced with * , so *city is the first byte
pointed to by city . In fact, pointers and arrays are often used
interchangeably, and the first char in the city array could be
referenced as city[0] or *city .''

This might mistakingly lead someone to believe that
pointers and arrays are one in the same if you do not
expound further on their differences.
``Note that C does no checks for validity of pointers, so *city
will likely cause a crash if city is uninitialized, and name[20]
gives an undefined result if name is allocated as above with room
for only 10 chars .''

C? You mean C implementations?
``Pointer arithmetic is allowed and automatically compensates
for the size of the element pointed to.''

I would use ``object'' not ``element''
``More generally, array[n] is equivalent to *(array + n) and in
fact is defined as such.''

No it isn't. It is equivalent to *((array) + (n))
The added parens are important. If your method
was actually used then the following would
fail:

a[i, j];

Which would be equivalent to *(a + i, j)

Which would end up dereferencing the value of ``j''
as opposed to *((a) + (i, j))
``typedef struct _record {
int element1; char element2;
struct _record * next;
} record, * record_ptr;''

The standard says that identifiers that begin with an
underscore are always reserved for use as identifiers
with file scope.

``int array[20];
for (i = 0; i < 20; i++)
{ { code involving array[i]; } }''
``i < sizeof array / sizeof array[0]''
is the more common convention

``Comments are denoted by // ;''

Only under c99 they are.
It doesn't matter if your c89/90 implementation
_happens_ to support them. That is, of course, if
portability is a concern.
I have written similar summaries for other languages and have or will
post them in the appropriate newsgroups.

Thank you.

- Adam Barr
ad****@gte.net

[Nils Petter Vaskinn]

On Tue, 24 Feb 2004 07:38:50 +0000, Richard Heathfield wrote:

Adam Barr wrote:

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.
It isn't.

So the pdf is real? I've seen the same post to other language groups (with
their language substituted obviously) so I assumed this was some kind of
scam using a vulnerability either in a common browser or a common pdf
reader.

To the OP: You will get better feedback if you provide the text as plain
text or html so that people could cut and paste the text when they
respond. I found one sentence that could be clarified, but when I couldn't
cut and paste that sentence easily (seems your pdf has some flag that
disallows selecting text in acroread) I didn't make the effort to read
through all of it.

In a pdf Adam Barr writes: An int holds an integer value, which can be 2, 4 or 8 bytes depending on
the platform. True because you used the word _can_ but those are not the only legal
sizes of int, wich somone might think after reading your sentence.
The value NULL is assigned to pointers to indicate that they point to
nothing.

Change that "is" to "can be". Your sentence could lead someone to believe
that assigning NULL is done automatically, which is not the case (though a
compiler _could_ choose to initialize all pointers to zero it's not
guaranteed to)

FWIW

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[John L]

"Adam Barr" <ad****@gte.net> wrote in message news:ce**************************@posting.google.c om...

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.

"blanks space" is a typo (and it is white space, as indeed you
call it later on).

"Arithmetic is as expected, with expressions grouped using parenthesis"
contains a typo and is at best misleading.

"char pointers are often assigned to constant strings" seems backwards.

Discussion of ++ is unhelpfully spread out.

Comments are used long before they are explained.

"If argument1 is an array, it is followed with []" is backwards;
argument1 might be declared as a pointer. (Imho this can cause
problems but that is a separate rant.)

By "functions with arguments that are replaced", you mean macros.

Your discussions of strings and structs are not quite right.

In places even the English used seems slightly odd.

There are also some curious omissions: so far as I can see,
neither libraries nor headers are mentioned.

Now, that is from a few minutes flicking through the text,
not properly reading it in sequence. It looks, however,
if it has been written in much the same fashion: as a series
of loosely connected thoughts about C. To judge it properly,
though, one would need to understand its purpose and target
audience. Perhaps an annotated sample program, a more
tutorial introduction, or a more systematic summary would
be better ways. Look at Kernighan & Ritchie for examples
of these approaches.

Remember too that an experienced programmer familiar with
any of the Algol-like languages (is that flame bait?) can
probably *read* most C code at least well enough to get
the general impression of what is going on. If this is
your target reader, then your introduction to C can
be more concise and concentrate on oddities like = vs ==
and so on.

HTH.

John.

[CBFalconer]

Adam Barr wrote:

.... snip ...
The information is in PDF form per my publisher's request, but if
this is a problem for anyone, email me and I can send it to you
in plain text.

The file is at

http://www.proudlyserving.com/language/c.pdf

I have written similar summaries for other languages and have or
will post them in the appropriate newsgroups.

Why don't you simply mount the text file within a zip for anyone
who wants it? Then all the normal tools, such as diff and grep
etc. will work on it.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Jeremy Yallop]

j wrote:

``Statements in C end with a semi-colon ( ; ).''

No, not true. By that definition the following
qualifies as a statement:

int foo;

``Dogs have four legs.''

No, not true. By that definition a cat qualifies as a dog.

Jeremy.

[Richard Bos]

Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:

j wrote:

``Statements in C end with a semi-colon ( ; ).''

No, not true. By that definition the following
qualifies as a statement:

int foo;

``Dogs have four legs.''

No, not true. By that definition a cat qualifies as a dog.

It's still not true. But since I have no desire to sponsor the OP's
business (and reputation, which without the help of c.l.c would've
suffered quite a blow) without getting some form of remuneration, I'm
certainly not going to help the commercial leech by telling him why.

Here's a comment he can put in his book, though: the writer of that PDF
is by no means competent enough to be teaching others the C language.

Richard

[Nils Petter Vaskinn]

On Tue, 24 Feb 2004 12:05:40 +0000, CBFalconer wrote:

Adam Barr wrote:

The information is in PDF form per my publisher's request, but if
this is a problem for anyone, email me and I can send it to you
in plain text.

Why don't you simply mount the text file within a zip for anyone
who wants it? Then all the normal tools, such as diff and grep
etc. will work on it.

The most probable reason seems to be that his publisher has the
(incorrect) idea that a pdf is safe from someone getting at the text. It
can't be to have the formatting because it sucks (unless something is
wrong with both acroread and ghostview)

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[Jeremy Yallop]

Richard Bos wrote:

Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:

j wrote:

> ``Statements in C end with a semi-colon ( ; ).''
>
> No, not true. By that definition the following
> qualifies as a statement:
>
> int foo;

``Dogs have four legs.''

No, not true. By that definition a cat qualifies as a dog.

It's still not true.

It (i.e. ``Statements in C end with a semi-colon ( ; ).'') is true
except for the degenerate case of an empty compound statement ("{}").

Jeremy.

[Richard Bos]

Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:

Richard Bos wrote:

Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:

j wrote:
> ``Statements in C end with a semi-colon ( ; ).''
>
> No, not true. By that definition the following
> qualifies as a statement:
>
> int foo;

``Dogs have four legs.''

No, not true. By that definition a cat qualifies as a dog.

It's still not true.

It (i.e. ``Statements in C end with a semi-colon ( ; ).'') is true
except for the degenerate case of an empty compound statement ("{}").

Wrong. And be a wise man - don't help the leech.

Richard

[Jeremy Yallop]

Richard Bos wrote:

Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:

Richard Bos wrote:

> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:
>
>> j wrote:
>> > ``Statements in C end with a semi-colon ( ; ).''
>> >
>> > No, not true. By that definition the following
>> > qualifies as a statement:
>> >
>> > int foo;
>>
>> ``Dogs have four legs.''
>>
>> No, not true. By that definition a cat qualifies as a dog.
>
> It's still not true.

It (i.e. ``Statements in C end with a semi-colon ( ; ).'') is true
except for the degenerate case of an empty compound statement ("{}").

Wrong.

Yes, sorry. A statement ends with either a semicolon or a (possibly
empty) brace-enclosed sequence of statements.

Jeremy.

[Eric Sosman]

Adam Barr wrote:

For a book I am working on, I have written a brief (7 page) summary
of C. The intent of this is that an experienced programmer who did
not know C would be able to get enough information to read and
understand C programs. It is not meant to be a 100% complete
summary of the language, but everything in there should be correct.
[...]

First sentence: "Statements in C end with a semi-colon (;)."
Incorrect, and "semicolon" is misspeleld.

Second sentence: "C treats all blanks [sic] space as equivalent.
so line breaks and indents are for readability only." Incorrect.

Third sentence: "Blocks of code are surrounded with braces, {
and }." Correct! Huzzah!

Fourth sentence: "A single statement without braces also counts
as a block." Either incorrect or meaningless; it's debatable.

Fifth sentence: "The basic data types in C are int and char."
Incorrect.

Sixth sentence: "An int holds an integer value, which can be
2, 4, or 8 bytes depending on the platform (none of the code here
depends on the exact length of an int)." Correct as far as it
goes, but incomplete.

Seventh sentence: "A char holds a single byte." Correct but
tautological.

... and so on. Not a promising start; I didn't read more than
a few sentences further. My general impression is that an honest
effort has been made, but that the author is not sufficiently
knowledgeable in his subject to avoid making simple errors.

(Don't feel too bad. I once took an introductory Java class
from a full Professor of Computer Science who got himself hopelessly
confused over Java's argument-passing semantics. The whole class
was sitting there trying to tell him he was completely wrong, but
nobody with a PhD was going to listen to a bunch of students ...)

--
Er*********@sun.com

[pete]

Adam Barr wrote:

http://www.proudlyserving.com/language/c.pdf

I have written similar summaries for other languages and have or will
post them in the appropriate newsgroups.

You call
c = 5
an assignment statement,
though it is clearly an assignment expression and not a statement.

The last paragraph of the page,
is not the best place to demonstrate that you have mastered
the use of the semicolon in the English language.

--
pete

[Adam Barr]

Thanks for the comments so far. On the issue of PDF vs. plain text, as
I said I was requested to post it as PDF, but I'll email it as plain
text to anyone who would prefer it in that format (which I agree is
more useful).

- adam

[Leor Zolman]

On 24 Feb 2004 12:57:56 -0800, ad****@gte.net (Adam Barr) wrote:

Thanks for the comments so far. On the issue of PDF vs. plain text, as
I said I was requested to post it as PDF, but I'll email it as plain
text to anyone who would prefer it in that format (which I agree is
more useful).

- adam

You /might/ facilitate getting more critiques if you simply re-post the PDF
after unchecking the "Do not allow...selecting text and graphics" checkbox
in Acrobat's security settings during the "Save as" operation... thus
saving yourself the emailing effort.
-leor

..
Leor Zolman
BD Software
le**@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

[Mark McIntyre]

On Tue, 24 Feb 2004 08:59:52 GMT, in comp.lang.c , Nils Petter Vaskinn
<[e-mail]> wrote:

respond. I found one sentence that could be clarified, but when I couldn't
cut and paste that sentence easily (seems your pdf has some flag that
disallows selecting text in acroread)

You may need a newer version of acroread - I can copy/paste fine using V5.0
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mike Wahler]

"Eric Sosman" <Er*********@sun.com> wrote in message
news:40***************@sun.com...

Incorrect, and "semicolon" is misspeleld.

:-)

-Mike

[Nils Petter Vaskinn]

On Tue, 24 Feb 2004 23:45:01 +0000, Mark McIntyre wrote:

On Tue, 24 Feb 2004 08:59:52 GMT, in comp.lang.c , Nils Petter Vaskinn
<[e-mail]> wrote:

respond. I found one sentence that could be clarified, but when I couldn't
cut and paste that sentence easily (seems your pdf has some flag that
disallows selecting text in acroread)

You may need a newer version of acroread - I can copy/paste fine using V5.0

Mine is V5.0 too. If we're talking about the same pdf file here. What os
are you running on? It may be an issue with RH9.

Crossposted and followups set to move this subthread out of clc.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[John Bode]

No mention of header files? main()?

It's like you've focused on a few random spelling rules in English,
but haven't described what a correct English sentence looks like.

I also recommend writing a short but complete C program (with at least
one subroutine to illustrate parameter passing conventions) and
annotating it.

[Dave Thompson]

On Tue, 24 Feb 2004 02:44:19 -0800, "j" <ja**********@bellsouth.net>
wrote:

"Adam Barr" <ad****@gte.net> wrote in message
news:ce**************************@posting.google.c om...

For a book I am working on, I have written a brief (7 page) summary
of C. <snip> the material is copyrighted, this document is
provided for review only, <snip>

<snip> ``C treats all blanks space as equivalent, so line breaks
and indents are for readability only.''

So #define FOO 10
is the same as #defineFOO10 ?
Aside from the typo and the fact that the conventional term is white
space or whitespace, with no comparand (or whatever it's called) this
can only be read as meaning one whitespace is equivalent to another
whitespace, which is correct except for preprocessor and literals; it
is not reasonable to read it as saying whitespace is equivalent to an
empty string. So a better counterexample is
#define FOO 10
#define FOO
10
or "this is a string" "this\tis\na string"

(points I more-or-less agree with snipped)
``More generally, array[n] is equivalent to *(array + n) and in
fact is defined as such.''

No it isn't. It is equivalent to *((array) + (n))
The added parens are important. If your method
was actually used then the following would
fail:

a[i, j];
which is of course silly anyway, unless i actually (expands to
something that) has (relevant) side effects
Which would be equivalent to *(a + i, j)

Which would end up dereferencing the value of ``j''
as opposed to *((a) + (i, j))
No it wouldn't; given a is an array or pointer, a[i,j] is legal only
if j is an integer type, in which case *(a+i,j) is a constraint
violation. I don't see any case *of this particular transform* where
extra parens are needed, although it wouldn't hurt to use them to
emphasize/clarify the atomicity of the components.
``int array[20];
for (i = 0; i < 20; i++)
{ { code involving array[i]; } }''
``i < sizeof array / sizeof array[0]''
is the more common convention

In this newsgroup it is, but IME not universally; a #define or
possibly enumerated value used in both places is also common, and
(sadly) so are magic numbers.

It is more automatically/robustly safe, especially when packaged in a
macro, and especially if you add one of the clever tricks to error out
on a pointer, and might better be promoted on those grounds.

But you may want to cast it to signed, or make i unsigned, for those
@#* compilers that warn noisily about comparing signed to unsigned.

- David.Thompson1 at worldnet.att.net

[Greg Barron]

On Mon, 01 Mar 2004 07:09:18 GMT, Dave Thompson
<da*************@worldnet.att.net> wrote:

On Tue, 24 Feb 2004 02:44:19 -0800, "j" <ja**********@bellsouth.net>
wrote:

"Adam Barr" <ad****@gte.net> wrote in message
news:ce**************************@posting.google.c om...

> For a book I am working on, I have written a brief (7 page) summary
> of C. <snip> the material is copyrighted, this document is
> provided for review only, <snip>

<snip>

``C treats all blanks space as equivalent, so line breaks
and indents are for readability only.''

So #define FOO 10
is the same as #defineFOO10 ?

Aside from the typo and the fact that the conventional term is white
space or whitespace, with no comparand (or whatever it's called) this
can only be read as meaning one whitespace is equivalent to another
whitespace, which is correct except for preprocessor and literals; it
is not reasonable to read it as saying whitespace is equivalent to an
empty string. So a better counterexample is
#define FOO 10
#define FOO
10

Where's your continuation? This won't work. You need:

#define FOO \
10

Cheers,
--
Greg.

[Nils Petter Vaskinn]

On Mon, 01 Mar 2004 18:55:24 +1100, Greg Barron wrote:

On Mon, 01 Mar 2004 07:09:18 GMT, Dave Thompson
<da*************@worldnet.att.net> wrote:

this
can only be read as meaning one whitespace is equivalent to another
whitespace, which is correct except for preprocessor and literals; it
is not reasonable to read it as saying whitespace is equivalent to an
empty string. So a better counterexample is
#define FOO 10
#define FOO
10

Where's your continuation? This won't work. You need:

I don't think it's intended to work. It's intended to prove that "all
whitespace isn't created equal" since in the example above a spece between
FOO and 10 isn't the same as a newline between FOO and 10
--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up