Re: C99 in standards.texi

[Alfred M. Szmidt]

   (It would help me a little for the autodate changes to be omitted from
   patches.  It's not like they will apply ...)

Will do!

   As I see it, this change is basically making consistent the two
   references to C99 in standards.texi.  Before, in one node we said
   "don't require it in new programs" and in another "you may want to
   take advantage of it".  Is that the idea?

That is exactly the idea.

   If so, I agree that we should change something, but my intuition is
   that the change should go in the other direction.  Do we really
   think it's ok to *require* C99 in new programs now?  Didn't we just
   have this discussion in gnulib and the answer was no?

I actually like the current wording, since it is only suggesting to
use C99 features (which I think should be encouraged, that standard is
10 years old now), not an requirement.  I changed the wording just
slightly to make it clearer, what do you think?

| Hence, there is little reason to support old C or non-POSIX systems,
| and you may want to take advantage of C99 and POSIX-1.2001 if they
| are available to write clearer, more portable, or faster code.

   Trivial: regarding your removal of "Despite the standards" in the
   last paragraph of the patch, I think that phrase is useful and want
   to keep it :).  People should not get the idea that just because a
   standard says XYZ, it can be relied on in the real world.  It
   can't.

Fair enough, I found the wording strange when there was nothing before
that sentence.  I tweaked it just a bit...

--- standards.texi.~1.208.~     2011-12-06 17:14:38.000000000 +0100
+++ standards.texi      2011-12-22 02:43:14.000000000 +0100
@@ -410,12 +410,20 @@
 @section Standard C and Pre-Standard C
 @cindex @sc{ansi} C standard
 
-1989 Standard C is widespread enough now that it is ok to use its
-features in new programs.  There is one exception: do not ever use the
-``trigraph'' feature of Standard C.
+Historically, C implementations differed substantially, and many
+systems lacked a full implementation of ANSI/ISO C89.  Nowadays,
+however, very few systems lack a C89 compiler and GNU C supports
+almost all of C99.  Similarly, most systems implement POSIX.1-1993
+libraries and tools, and many have POSIX.1-2001.
 
-1999 Standard C is not widespread yet, so please do not require its
-features in programs.  It is ok to use its features if they are present.
+Hence, there is little reason to support old C or non-POSIX systems,
+and you may want to take advantage of C99 and POSIX-1.2001 if they are
+available to write clearer, more portable, or faster code.  There is
+one exception: do not ever use the ``trigraph'' feature of Standard C.
+You should use standard interfaces where possible; but if GNU
+extensions make your program more maintainable, powerful, or otherwise
+better, don't hesitate to use them.  In any case, don't make your own
+declaration of system functions; that's a recipe for conflict.
 
 However, it is easy to support pre-standard compilers in most programs,
 so if you know how to do that, feel free.  If a program you are
@@ -2973,21 +2981,7 @@
 @cindex library functions, and portability
 @cindex portability, and library functions
 
-Historically, C implementations differed substantially, and many
-systems lacked a full implementation of ANSI/ISO C89.  Nowadays,
-however, very few systems lack a C89 compiler and GNU C supports
-almost all of C99.  Similarly, most systems implement POSIX.1-1993
-libraries and tools, and many have POSIX.1-2001.
-
-Hence, there is little reason to support old C or non-POSIX systems,
-and you may want to take advantage of C99 and POSIX-1.2001 to write
-clearer, more portable, or faster code.  You should use standard
-interfaces where possible; but if GNU extensions make your program
-more maintainable, powerful, or otherwise better, don't hesitate to
-use them.  In any case, don't make your own declaration of system
-functions; that's a recipe for conflict.
-
-Despite the standards, nearly every library function has some sort of
+Despite standards, nearly every library function has some sort of
 portability issue on some system or another.  Here are some examples:
 
 @table @code