I am a C++ programmer by trade and am not current on the ISO C99
standard nor the complete differences between them.  I am aware of
some which I consider useful to allow in my class.  I plan on
compling students' assignments  with:

gcc -std=c99 -Wall -pedantic

Any opinions on this?

Anyone have an opinion about using the K&R book and basically teaching
C89 but allowing C99 code?  

Is there anyting in C99 which would cause valid C89 code to fail with
the above options?  Surely not.

A reference to the differences between C89 and C99 would be useful if
anyone has one.

Thanks

More minor things include the introduction of // comments which in
pathological cases can cause a different program behaviour:
  if (1 //**/ 2
     )
  {
    puts("C99");
  }
  else
  {
    puts("C89");
  }

restricted character set support via digraphs and <iso646.h> (originally
specified in AMD1)
wide character library support in <wchar.h> and <wctype.h> (originally
specified in AMD1)
more precise aliasing rules via effective type
restricted pointers
variable-length arrays
flexible array members
static and type qualifiers in parameter array declarators
complex (and imaginary) support in <complex.h>
type-generic math macros in <tgmath.h>
the long long int type and library functions
increased minimum translation limits
additional floating-point characteristics in <float.h>
remove implicit int
reliable integer division
universal character names (\u and \U)
extended identifiers
hexadecimal floating-point constants and %a and %A printf/scanf
conversion specifiers
compound literals
designated initializers
// comments
extended integer types and library functions in <inttypes.h> and
<stdint.h>
remove implicit function declaration
preprocessor arithmetic done in intmax_t/uintmax_t
mixed declarations and code
new block scopes for selection and iteration statements
integer constant type rules
integer promotion rules
macros with a variable number of arguments
the vscanf family of functions in <stdio.h> and <wchar.h>
additional math library functions in <math.h>
floating-point environment access in <fenv.h>
IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
trailing comma allowed in enum declaration
%lf conversion specifier allowed in printf
inline functions
the snprintf family of functions in <stdio.h>
boolean type in <stdbool.h>
idempotent type qualifiers
empty macro arguments
new struct type compatibility rules (tag compatibility)
additional predefined macro names
_Pragma preprocessing operator
standard pragmas
__func__ predefined identifier
VA_COPY macro
additional strftime conversion specifiers
LIA compatibility annex
deprecate ungetc at the beginning of a binary file
remove deprecation of aliased array parameters
conversion of array to pointer not limited to lvalues
relaxed constraints on aggregate and union initialization
relaxed restrictions on portable header names
return without expression not permitted in function that returns a value
(and vice versa)

main(void) {
  return 0;

There are also some keywords like restrict which might cause some problems.

o new types - bool (stdbool.h), many new integer types (stdint.h), complex
types (complex.h), long long...
o variable length arrays
o a whole load of new library features including type generic math
(tgmath.h), support for wide characters, changes to things like printf to
support the new types, some new functions like vfscanf...
o expanded limits (things like the largest allocatable block of memory
extended from 32768 chars to 65536 chars, or something)
o changes to the character set support for national characters and wide
characters
o variable length 'argument lists' in function-like macros
o declarations can now be mixed with code (ala C++, but the behaviour is
likely to be a little different)
o compound literals (so you can do things like initialise a while structure
variable)
o restricted pointers
o 'inline'
o a new meaning for the word static
o implicit 'int' no longer allowed
o C++/BCPL? style // comments

and probably a few other things which I've skipped over.

Many of these things won't effect your students, though some will.

- Do not cast the return value of realloc, malloc, calloc or any void *
  when assigning. (as opposed to C++)
- sizeof 'a' == sizeof(int) (as opposed to C++)
  This one has more implications than you can shake a stick at when it
  comes to C vs C++. (Maybe not that many :)

Also, I found this amazing site the other day, they have everything
you can possibly ask for (and probably a lot more). www.google.com ;)

--
Thomas.

--Ben

Add -ansi to prevent the "violative" GNU extensions from being
accepted silently.  (Note that the "permitted" extension forms,
like __attribute__ instead of attribute, are still accepted, although
in my personal opinion any student who gets this right probably
deserves to get away with it.)  Even with recent gcc (and glibc)
C99 support is not quite complete -- there's a status page at
gcc.gnu.org IIRC -- but the deficiencies are mostly pretty minor
and I think unlikely to be an issue for student programs,
even if some students get a better-conforming C99.

Note that -Wall doesn't actually enable all warnings (see the info
file).  You may want to add -W, although I don't recall offhand
that any of the checks/warnings it adds are relevant to standard
conformance, though sometimes useful in their own right.

Deletion of implicit int in declarations, and implicit function declarations,
both of which were bad style anyway and thus you shouldn't allow.
(And were illegal in C++ from the beginning, FWIW.  Although K&R1
syntax function declarations and definitions were never legal in C++,
but are still legal though 'obsolescent' in C99.)

No longer guaranteeing that certain implementation-defined types,
particularly size_t, cannot be wider than, and thus can safely be
printed or otherwise handled as, unsigned long.  Also (possibly)
increase the type for evaluating preprocessor (#if) expressions,
and change the default type of large (> signed long) constants.
I doubt these will matter for student programs.

Or you can post here at need and lots of folks will be standing by
to pounce on any mistake you or your students make.
(I can't decide whether that deserves a smiley or not.  You choose.)