Re: [gnu-prog-discuss] An experimental GNU Assembly

[Alfred M. Szmidt]

   >> And as I said, multiple times now, I think this is a good idea.
   >> Please raise it.  It won't get done by it self, nor by repeating
   >> it.
   >
   > I have raised it; my suggestion was rejected.

   I think this was wrong, and out of touch with reality.

To be precies, the patch as such by Rueben changed some K&R-ish
specific cavets, it didn't change the C standard to recommend.  I
think these cavets are still useful, mostly since I encounterd them on
a platform or two.

  http://lists.gnu.org/archive/html/bug-standards/2011-12/msg00000.html

For reference, this is what GCS says about C versions (section
`Calling System 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.

But, the section Reuben had a problem with I think was `Standard C and
Pre-Standard C', whic states:

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

Which conflicts with the previously mentioned section.

   Reuben, please rewrite your patch as multiple small changes and Cc 
   address@hidden on the set.

Do you mean bug-standards?


Karl, what do you think about the following change?

*** standards.texi.~1.208.~     Tue Dec  6 17:14:38 2011
--- standards.texi      Wed Dec 21 00:02:59 2011
***************
*** 3,9 ****
  @setfilename standards.info
  @settitle GNU Coding Standards
  @c This date is automagically updated when you save this file:
! @set lastupdate December 4, 2011
  @c %**end of header
  
  @dircategory GNU organization
--- 3,9 ----
  @setfilename standards.info
  @settitle GNU Coding Standards
  @c This date is automagically updated when you save this file:
! @set lastupdate December 21, 2011
  @c %**end of header
  
  @dircategory GNU organization
***************
*** 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