From 29f92b6f9f4c550381a57e41bf0ce4d330bc60f5 Mon Sep 17 00:00:00 2001 From: "Richard M. Stallman" Date: Mon, 26 Feb 1996 21:14:03 +0000 Subject: [PATCH] It is ok now to write in ANSI C. --- doc/standards.texi | 87 ++++++++++++++++++++++++++++++++++------------ standards.texi | 87 ++++++++++++++++++++++++++++++++++------------ 2 files changed, 128 insertions(+), 46 deletions(-) diff --git a/doc/standards.texi b/doc/standards.texi index 095df0c5..b4b81e9a 100644 --- a/doc/standards.texi +++ b/doc/standards.texi @@ -201,6 +201,7 @@ account when designing your program. @menu * Compatibility:: Compatibility with Other Implementations * Using Extensions:: Using Non-standard Features +* ANSI C:: Using ANSI C features * Source Language:: Using Languages Other Than C * Portability:: Portability As It Applies to GNU @end menu @@ -208,16 +209,16 @@ account when designing your program. @node Compatibility @section Compatibility with Other Implementations -@c ADR: What are the exceptions? -With certain exceptions, utility programs and libraries for GNU should -be upward compatible with those in Berkeley Unix, and upward compatible -with @sc{ANSI} C if @sc{ANSI} C specifies their behavior, and upward -compatible with @sc{POSIX} if @sc{POSIX} specifies their behavior. +With occasional exceptions, utility programs and libraries for GNU +should be upward compatible with those in Berkeley Unix, and upward +compatible with @sc{ansi} C if @sc{ansi} C specifies their behavior, and +upward compatible with @sc{POSIX} if @sc{POSIX} specifies their +behavior. When these standards conflict, it is useful to offer compatibility modes for each of them. -@sc{ANSI} C and @sc{POSIX} prohibit many kinds of extensions. Feel +@sc{ansi} C and @sc{POSIX} prohibit many kinds of extensions. Feel free to make the extensions anyway, and include a @samp{--ansi}, @samp{--posix}, or @samp{--compatible} option to turn them off. However, if the extension @@ -272,10 +273,51 @@ order to bootstrap the GNU compilation facilities. If these require the GNU compiler, then no one can compile them without having them installed already. That would be no good. -Since most computer systems do not yet implement @sc{ANSI} C, using the -@sc{ANSI} C features is effectively using a GNU extension, so the -same considerations apply. (Except for @sc{ANSI} features that we -discourage, such as trigraphs---don't ever use them.) +@node ANSI C +@section @sc{ansi} C and pre-@sc{ansi} C + +Do not ever use the ``trigraph'' feature of @sc{ansi} C. + +@sc{ansi} C is widespread enough now that it is ok to write new programs +that use @sc{ansi} C features (and therefore will not work in +non-@sc{ansi} compilers). And if a program is already written in +@sc{ansi} C, there's no need to convert it to support non-@sc{ansi} +compilers. + +However, it is easy to support non-@sc{ansi} compilers in most programs, +so you might still consider doing so when you write a program. Instead +of writing function definitions in @sc{ansi} prototype form, + +@example +int +foo (int x, int y) +@dots{} +@end example + +@noindent +write the definition in pre-@sc{ansi} style like this, + +@example +int +foo (x, y) + int x, y; +@dots{} +@end example + +@noindent +and use a separate declaration to specify the argument prototype: + +@example +int foo (int, int); +@end example + +You need such a declaration anyway, in a header file, to get the benefit +of @sc{ansi} C prototypes in all the files where the function is called. +And once you have it, you lose nothing by writing the function +definition in the pre-@sc{ansi} style. + +If you don't know non-@sc{ansi} C, there's no need to learn it; just +write in @sc{ansi} C. @node Source Language @section Using Languages Other Than C @@ -1714,7 +1756,7 @@ concat (s1, s2) /* Name starts in column zero here */ @end example @noindent -or, if you want to use @sc{ANSI} C, format the definition like this: +or, if you want to use @sc{ansi} C, format the definition like this: @example static char * @@ -1724,7 +1766,7 @@ concat (char *s1, char *s2) @} @end example -In @sc{ANSI} C, if the arguments don't fit nicely on one line, +In @sc{ansi} C, if the arguments don't fit nicely on one line, split it like this: @example @@ -2046,14 +2088,12 @@ this. @code{doschk} also tests for potential name conflicts if the files were loaded onto an MS-DOS file system---something you may or may not care about. - - @node System Functions @section Calling System Functions -C implementations differ substantially. ANSI C reduces but does not +C implementations differ substantially. @sc{ansi} C reduces but does not eliminate the incompatibilities; meanwhile, many users wish to compile -GNU software with pre-ANSI compilers. This chapter gives +GNU software with pre-@sc{ansi} compilers. This chapter gives recommendations for how to use the more or less standard C library functions to avoid unnecessary loss of portability. @@ -2077,7 +2117,7 @@ contrast, actual declarations have frequently caused actual conflicts. @item If you must declare a system function, don't specify the argument types. -Use an old-style declaration, not an ANSI prototype. The more you +Use an old-style declaration, not an @sc{ansi} prototype. The more you specify about the function, the more likely a conflict. @item @@ -2109,7 +2149,7 @@ figure out which file to include, or don't include either file. If you don't include either strings file, you can't get declarations for the string functions from the header file in the usual way. -That causes less of a problem than you might think. The newer ANSI +That causes less of a problem than you might think. The newer @sc{ansi} string functions are off-limits anyway because many systems still don't support them. The string functions you can use are these: @@ -2139,11 +2179,12 @@ names, but neither pair works on all systems. You should pick a single pair of names and use it throughout your program. (Nowadays, it is better to choose @code{strchr} and -@code{strrchr}.) Declare both of those names as functions returning -@code{char *}. On systems which don't support those names, define them -as macros in terms of the other pair. For example, here is what to put -at the beginning of your file (or in a header) if you want to use the -names @code{strchr} and @code{strrchr} throughout: +@code{strrchr}, since those are the standard @sc{ansi} names.) Declare +both of those names as functions returning @code{char *}. On systems +which don't support those names, define them as macros in terms of the +other pair. For example, here is what to put at the beginning of your +file (or in a header) if you want to use the names @code{strchr} and +@code{strrchr} throughout: @example #ifndef HAVE_STRCHR diff --git a/standards.texi b/standards.texi index 095df0c5..b4b81e9a 100644 --- a/standards.texi +++ b/standards.texi @@ -201,6 +201,7 @@ account when designing your program. @menu * Compatibility:: Compatibility with Other Implementations * Using Extensions:: Using Non-standard Features +* ANSI C:: Using ANSI C features * Source Language:: Using Languages Other Than C * Portability:: Portability As It Applies to GNU @end menu @@ -208,16 +209,16 @@ account when designing your program. @node Compatibility @section Compatibility with Other Implementations -@c ADR: What are the exceptions? -With certain exceptions, utility programs and libraries for GNU should -be upward compatible with those in Berkeley Unix, and upward compatible -with @sc{ANSI} C if @sc{ANSI} C specifies their behavior, and upward -compatible with @sc{POSIX} if @sc{POSIX} specifies their behavior. +With occasional exceptions, utility programs and libraries for GNU +should be upward compatible with those in Berkeley Unix, and upward +compatible with @sc{ansi} C if @sc{ansi} C specifies their behavior, and +upward compatible with @sc{POSIX} if @sc{POSIX} specifies their +behavior. When these standards conflict, it is useful to offer compatibility modes for each of them. -@sc{ANSI} C and @sc{POSIX} prohibit many kinds of extensions. Feel +@sc{ansi} C and @sc{POSIX} prohibit many kinds of extensions. Feel free to make the extensions anyway, and include a @samp{--ansi}, @samp{--posix}, or @samp{--compatible} option to turn them off. However, if the extension @@ -272,10 +273,51 @@ order to bootstrap the GNU compilation facilities. If these require the GNU compiler, then no one can compile them without having them installed already. That would be no good. -Since most computer systems do not yet implement @sc{ANSI} C, using the -@sc{ANSI} C features is effectively using a GNU extension, so the -same considerations apply. (Except for @sc{ANSI} features that we -discourage, such as trigraphs---don't ever use them.) +@node ANSI C +@section @sc{ansi} C and pre-@sc{ansi} C + +Do not ever use the ``trigraph'' feature of @sc{ansi} C. + +@sc{ansi} C is widespread enough now that it is ok to write new programs +that use @sc{ansi} C features (and therefore will not work in +non-@sc{ansi} compilers). And if a program is already written in +@sc{ansi} C, there's no need to convert it to support non-@sc{ansi} +compilers. + +However, it is easy to support non-@sc{ansi} compilers in most programs, +so you might still consider doing so when you write a program. Instead +of writing function definitions in @sc{ansi} prototype form, + +@example +int +foo (int x, int y) +@dots{} +@end example + +@noindent +write the definition in pre-@sc{ansi} style like this, + +@example +int +foo (x, y) + int x, y; +@dots{} +@end example + +@noindent +and use a separate declaration to specify the argument prototype: + +@example +int foo (int, int); +@end example + +You need such a declaration anyway, in a header file, to get the benefit +of @sc{ansi} C prototypes in all the files where the function is called. +And once you have it, you lose nothing by writing the function +definition in the pre-@sc{ansi} style. + +If you don't know non-@sc{ansi} C, there's no need to learn it; just +write in @sc{ansi} C. @node Source Language @section Using Languages Other Than C @@ -1714,7 +1756,7 @@ concat (s1, s2) /* Name starts in column zero here */ @end example @noindent -or, if you want to use @sc{ANSI} C, format the definition like this: +or, if you want to use @sc{ansi} C, format the definition like this: @example static char * @@ -1724,7 +1766,7 @@ concat (char *s1, char *s2) @} @end example -In @sc{ANSI} C, if the arguments don't fit nicely on one line, +In @sc{ansi} C, if the arguments don't fit nicely on one line, split it like this: @example @@ -2046,14 +2088,12 @@ this. @code{doschk} also tests for potential name conflicts if the files were loaded onto an MS-DOS file system---something you may or may not care about. - - @node System Functions @section Calling System Functions -C implementations differ substantially. ANSI C reduces but does not +C implementations differ substantially. @sc{ansi} C reduces but does not eliminate the incompatibilities; meanwhile, many users wish to compile -GNU software with pre-ANSI compilers. This chapter gives +GNU software with pre-@sc{ansi} compilers. This chapter gives recommendations for how to use the more or less standard C library functions to avoid unnecessary loss of portability. @@ -2077,7 +2117,7 @@ contrast, actual declarations have frequently caused actual conflicts. @item If you must declare a system function, don't specify the argument types. -Use an old-style declaration, not an ANSI prototype. The more you +Use an old-style declaration, not an @sc{ansi} prototype. The more you specify about the function, the more likely a conflict. @item @@ -2109,7 +2149,7 @@ figure out which file to include, or don't include either file. If you don't include either strings file, you can't get declarations for the string functions from the header file in the usual way. -That causes less of a problem than you might think. The newer ANSI +That causes less of a problem than you might think. The newer @sc{ansi} string functions are off-limits anyway because many systems still don't support them. The string functions you can use are these: @@ -2139,11 +2179,12 @@ names, but neither pair works on all systems. You should pick a single pair of names and use it throughout your program. (Nowadays, it is better to choose @code{strchr} and -@code{strrchr}.) Declare both of those names as functions returning -@code{char *}. On systems which don't support those names, define them -as macros in terms of the other pair. For example, here is what to put -at the beginning of your file (or in a header) if you want to use the -names @code{strchr} and @code{strrchr} throughout: +@code{strrchr}, since those are the standard @sc{ansi} names.) Declare +both of those names as functions returning @code{char *}. On systems +which don't support those names, define them as macros in terms of the +other pair. For example, here is what to put at the beginning of your +file (or in a header) if you want to use the names @code{strchr} and +@code{strrchr} throughout: @example #ifndef HAVE_STRCHR