Mail Archives: geda-help/2012/01/22/18:48:35
This is quite off-topic for this list, but I have some comments
Darryl may find useful.
On Sun, Jan 22, 2012 at 04:22:00PM -0500, John Hudak wrote:
> Hi Darryl:
>
> - 'a getter'.....yep, I thought the same thing- back in the day of
> designing tubes.....
> - a caution about learning C - (and this is my opinion after teaching and
> observing lots of students) - you can 'hang' yourself lots of ways in C.
> IMHO, just as important as learning the language syntax and semantics is
> learning the pitfalls. Here is a ref to something I reference in class:
> http://www.csd.uwo.ca/~moreno/cs2211_moreno/ctraps-AKoenig.pdf
> If you google C pitfalls, you will find lots of docs.
>
This document contains many pitfalls that no longer exist since C89
was ratified (over twenty years ago now). For example, the C standard
guaratees that the characters '0', '1', ..., '9' appear in consecutive
order (though it does not do so for 'a', ..., 'z' or 'A', ..., 'Z').
Signed and unsigned integer types are guaranteed to exist, and excepting
char, all are guaranteed to be signed by default. Further,
char must be >= 7 bits
short must be >= 16 bits
int must be >= 16 bits
long must be >= 32 bits
Free'd memory absolutely MUST NOT be accessed later. The realloc hack
given in the document is illegal and will break on pretty-much any modern
OS.
Function pointers may not be assigned object pointers, or vice-versa.
Function pointers may not be NULL. The snippit ((void (*)(void)) 0)()
is illegal for this reason.
Function pointers may not be casted to function pointers of different
types. (This is very irritating, but it's what the standard says.)
Calling a function with an invalid declaration is even worse, since it
has the same effect without warning the compiler. For example, the author
does the following:
char *malloc();
char *s = malloc(BUFSIZ);
which tells the compiler that malloc() is a function declared as
char *malloc (int);
when in fact it is
void *malloc(size_t);
This is not labelled a pitfall, but it is. If you want malloc, include
<stdlib.h>. This will give you the correct signature.
Finally, gcc and its linker will warn about the majority of the stylistic
errors in the document, so the language is actually far less terrifying
than it seems.
> If you are interested in a good book for learning C, this is one of my
> favorites:
> Engineering Problem Solving with C, Delores Etter
>
> Purists will point to the Kerhanan & Ritchey book, which is a great
> reference but is a little tough to plow through to learn the language.
>
Note that only the second edition contains ANSI standard C; the first
is considered useless, even by purists.
> In some programming languages, particularly for C, the knowledge of some
> C coding standards is very helpful. I would like to think that the ppl in
> this group use some standard. Hopefully it is documented. If not, if you
> look around the web you will find C coding standards and styles that are
> commonly used. - Delores Etters book contains a lot practices that good C
> coders follow.
>
The gEDA code follows the GNU coding standard. The basics can be picked
up quickly by looking at existing code.
--
Andrew Poelstra
Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net
Web: http://www.wpsoftware.net/andrew
"I don't understand. Are you saying dualism is always good, or always bad?"
- Raw text -