🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac.programmer.codewarrior
Article #24

Re: ANSI standards

#24
From: James Kanze US/ESC 60/3/141 #407...
Date: Mon, 18 Dec 1995 19:21
91 lines
3845 bytes
In article <30D57365.212D@cmt.lpr.mail.carel.fi> Ari Lukumies
<aril@cmt.lpr.mail.carel.fi> writes:

|> The ANSI standard states these formats for main:

|>   int	main(int argc, char **argv, char **env);
|>   int	main(int argc, char **argv);
|>   int	main(void);

|> Or you can use void as the return type.

Could you please quote chapter and verse.  My draft standard states
that "An implementation shall allow both of the following definitions
for main:

	int main() { /* ... */ }

and

	int main( int argc , char* argv[] ) { /* ... */ }

Nothing about a third parameter, and nothing about void.  This
represents no change with regards to C.

An implementation may allow any additional forms it wishes.  Posix, I
believe, requires also supporting the form:

	int main( int argc , char* argv[] , char* env[] ) //  ...

(Since the original posting was cross-posted to a Mac group, however,
I presume that the poster is not particularly interested in Posix
extensions to C.)

|> Some compilers make 
|> you explicitly state that you want ANSI compilation (eg, 
|> cc in HP-UX uses the flag -Aa), otherwise they don't recognize 
|> the ANSI prototypes, in which case you'd use

|>   int	main()
|>   int	main(argc, argv) int argc; char **argv; { ... }

|> or just plain

|>   main()

|> variants without the return type.

You seem to be confusing languages.  In C++, the first declaration
above is exactly the same as ``int main( void )'', and the second is
illegal.

The third is also illegal in C++, and will probably be deprecated in
the next C standard.

|> ANSI declares that there should be a compiler predefined 
|> identifier __STDC__ you can use for checking if the compiler 
|> is ANSI-compliant:

|>   #ifdef __STDC__
|>   ...
|>   #else
|>   ...
|>   #endif

Again, to quote the draft standard: "Whether __STDC__ is defined, and
if so, what its value is, are implementation defined."

The C standard requires conformant compilers to define __STDC__ to 1.
In practice, this has not been particularly effective, since of
course, the C standard cannot say anything about non-conformant
compilers, and many of them also define __STDC__.

|> Unfortunately, ANSI standard contains more than just the 
|> compiler, which has lead to many misuses considering the other 
|> parts of the compiling system, mainly the runtime libraries 
|> and header file names/functions. Many compiler vendors _do_ 
|> use the __STDC__ identifier but to only mark their _compiler_ 
|> as ANSI-compliant; they do not use it to tell that their 
|> libraries are also ANSI-compliant, and generally they are not. 
|> So I suggest you just go and test each and every 
|> compiler/platform and use some #define of your own to 
|> distinguish between them.

This is especially important given the number of recent features, that
are not supported by most current compilers.  In practice, I would
recommend a #define per missing feature.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone
Technical Details
Message-ID: <KANZE.95Dec18202147@slsvewt.lts.sel.alcatel.de>
Path: arc1-ca.pugleaf.net!blackbush.xlink.net!slsv6bt!slsv6bt!kanze
References: <1995Dec14.120627.31590@ucl.ac.uk> <4b2me3$a8c@news.aloha.com> <30D57365.212D@cmt.lpr.mail.carel.fi>

Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.mac.programmer.codewarrior,comp.lang.c++
Path: arc1-ca.pugleaf.net!blackbush.xlink.net!slsv6bt!slsv6bt!kanze
From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: ANSI standards
In-Reply-To: Ari Lukumies's message of Mon, 18 Dec 1995 15:57:57 +0200
Message-ID: <KANZE.95Dec18202147@slsvewt.lts.sel.alcatel.de>
Sender: news@lts.sel.alcatel.de
Organization: SEL
References: <1995Dec14.120627.31590@ucl.ac.uk> <4b2me3$a8c@news.aloha.com>
 <30D57365.212D@cmt.lpr.mail.carel.fi>
Date: 18 Dec 1995 19:21:45 GMT