bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

C99 in standards.texi


From: Karl Berry
Subject: C99 in standards.texi
Date: Wed, 21 Dec 2011 15:33:27 -0800

Hi Alfred,

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

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?

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?


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.

Thanks,
karl


*** standards.texi.~1.208.~     Tue Dec  6 17:14:38 2011
--- standards.texi      Wed Dec 21 00:02:59 2011
***************
*** 410,421 ****
  @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.

! 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.

  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
--- 410,429 ----
  @section Standard C and Pre-Standard C
  @cindex @sc{ansi} C standard

! 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.  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,2994 ****
  @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
! portability issue on some system or another.  Here are some examples:

  @table @code
  @item open
--- 2981,2988 ----
  @cindex library functions, and portability
  @cindex portability, and library functions

! Nearly every library function has some sort of portability issue on
! some system or another.  Here are some examples:

  @table @code
  @item open




reply via email to

[Prev in Thread] Current Thread [Next in Thread]