[CMake] several questions about cmake

Mark Roden mmroden at gmail.com
Fri Aug 27 12:32:36 EDT 2010


Sorry about breaking the back-thread, I only saw the response in the
cmake digest and not from a particular response.

I think that this code is suspicious anyway, for a number of reasons.
They claim out-of-the-box windows compatibility, but I'm getting all
sorts of other compilation errors that indicate that this code isn't
of the highest Windows quality.  For instance, neglecting these two
defines:

#	define ENAMETOOLONG			WSAENAMETOOLONG
#	define ENOTEMPTY			WSAENOTEMPTY

and assuming that sys/signal.h exists across all platforms while not
making the same assumption about sys/types.h.

Looks like I'm gonna have to (re)learn sockets, at least enough to
polish this up to make it useful.

To paraphrase Homer J:
"Learning?  That wasn't part of the deal!"

Ah well :)

Thanks for the help,
Mark

On Fri, Aug 27, 2010 at 9:31 AM, Jed Brown <jed at 59a2.org> wrote:
> Quoth Stroustrup (http://www2.research.att.com/~bs/bs_faq2.html#void-main):
>
>  The definition
>
>          void main() { /* ... */ }
>
>  is not and never has been C++, nor has it even been C. See the ISO C++
>  standard 3.6.1[2] or the ISO C standard 5.1.2.2.1. A conforming
>  implementation accepts
>
>          int main() { /* ... */ }
>
>  and
>
>          int main(int argc, char* argv[]) { /* ... */ }
>
>  A conforming implementation may provide more versions of main(), but
>  they must all have return type int. The int returned by main() is a way
>  for a program to return a value to "the system" that invokes it. On
>  systems that doesn't provide such a facility the return value is
>  ignored, but that doesn't make "void main()" legal C++ or legal C. Even
>  if your compiler accepts "void main()" avoid it, or risk being
>  considered ignorant by C and C++ programmers.
>
>
> Mark, you may be correct that it's not the reason for the failure (I
> haven't read the back-thread, which you broke) but I would be very
> suspicious of code that is non-conforming.
>
> Jed
>


More information about the CMake mailing list