c++'98 standard 
(http://www.kuzbass.ru:8086/docs/isocpp/basic.html#basic.start.main) clearly 
states that main _MUST_ have int as it's return type. Further it shall be 
callable as

int main();
int main(int argc, char* argv[]);

The part that says "but otherwise its type is implementation-defined" refers to 
the function arguments which are implementation-defined (except for the above 
two forms). E.g. most implementations also pass a pointer to a table containing 
environment variables, on Mac OS X you get additionally a pointer to an 
so-called apple-argument vector, containing e.g. the absolute path of the 
executable (where argv[0] in contrast can contain an arbitrary string if main 
is e.g. called by execve()).

So, any conforming compiler MUST accept "int main()", while "void main()" is a 
compiler extension, and probably supported by some compilers to accommodate 
pre-ISO standard code.

And the test is probably more concerned with the fact that sometimes on very 
old/bad systems you need to surround things like "#include <stdio.h>" with 
extern "C" statements because the implementors of the C standard library didn't 
do so.

Michael

On 27. Aug, 2010, at 17:45 , Mark Roden wrote:

> Hi Jed,
> 
> I don't want portable code.  I want the socket++ code that I
> originally got from someone else to compile as intended on the various
> platforms they support.  They put a void as a return type; that void
> as a return type is compiling just fine on vs2008, which according to
> that page, is perfectly legal behavior for that compiler.  This code
> is part of a config file, so I figure that if the test fails, then
> that means that socket++ was intended to run with extern 'c' wrapping
> around various functions.
> 
> Are they correct?  I don't know.  Does it work for me?  Yes.
> 
> You are right that C++ is not a strict superset of C ( at least
> according to http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B;
> I'm a big fan of sources), but in this instance, it looks like some
> compiler vendors were under that impression. I can only assume that
> the original authors of the library were as well, and wrote their code
> accordingly.  I don't have the expertise in their domain (networking)
> to be provide useful debugging.
> 
> Thanks,
> Mark
> 
> On Fri, Aug 27, 2010 at 8:30 AM, Jed Brown <j...@59a2.org> wrote:
>> On Fri, 27 Aug 2010 08:10:49 -0700, Mark Roden <mmro...@gmail.com> wrote:
>>> And it turns out that it is valid C++ to have
>>> void main()
>>> 
>>> because it's valid C.
>>> 
>>> Source:
>>> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/legality-of-void-main.html
>> 
>> You seem to have misread the link (which appears to falsely assert that
>> "otherwise its type is implementation-defined" is functionally different
>> from "some other implementation-defined manner").
>> 
>> The validity is implementation-defined, it is not standard C or C++.
>> And C++ is not a superset of C (far from it), so even if the C standard
>> did guaratee that returning void was supported (it doesn't), it would
>> not imply that C++ supports it.
>> 
>> If you want portable code, main must return int.
>> 
>> Jed
>> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to