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
