why does Erlang define macros reserved for the C compiler?

Rick Pettit rpettit@REDACTED
Thu May 18 15:05:43 CEST 2006


On Thu, May 18, 2006 at 10:37:04AM +0200, Bengt Kleberg wrote:
> On 2006-05-17 19:38, Matthias Lang wrote:
> >I'm looking at erts/emulator/beam/sys.h.
> 
> ...deleted
> >  _POSIX_SOURCE
> >  _XOPEN_SOURCE
> 
> > Does anybody know more?
> 
> if the question included the ones above then these 2 are feature test 
> macros. eg, if you want to compile a file so that it only depends upon 
> posix limits (and no implementation-defined limits) you should define 
> _POSIX_SOURCE.

For more information you can checkout:

  "Advanced UNIX Programming 2nd Edition" by Rochkind

                and/or

  http://www.unix.org/version3/

If you want to ask the compiler to enforce compliance with one of the many
standards (e.g. POSIX1988, POSIX1990, POSIX1993, POSIX1996, XPG3, SUS1, SUS2,
SUS3) you must communicate with the compiler via macros. To tell the compiler
what you want you set various macros (e.g. _POSIX_SOURCE), and to get feedback
from the compiler on what is available you check for various macros set by
the compiler (e.g. _POSIX_VERSION).

Of course there is a nasty catch summarized in AUP2Ed by Rochkind:

  "Systems like FreeBSD and Darwin are pretty conservative in their claims of
   POSIX conformance, yet they're much more complete than pure POSIX1988 or
   POSIX1990 system, which included neither socket-style networking nor
   SystemV IPC. FreeBSD has those features, which mostly work just as they're
   supposed to, and lots more."

So, on those systems if you write text-book standards compliant code you might
not be able to take advantage of features which they support (like sockets).

As a result it would appear as though writing standards-compliant code is much
more difficult/tricky than many people are aware (myself included prior to 
reading what a mess it often becomes).

-Rick



More information about the erlang-questions mailing list