Whats the deal with _INCLUDE_xxxx_SOURCE?
The ANSI standard clearly states what identifiers it reserves, and says the rest are available to you, the programmer. Many “important things” like “ulong” are *not* specified by ANSI, so ANSI header files are not allowed by the standard to define them. Each standard supported by HP-UX (POSIX1, POSIX2, XPG2, XPG3, XPG4, AES, etc) has its own set of reserved identifiers and header files, and the convention is to require “-D_POSIX_SOURCE” (et al) to enabled their respective namespaces. Since HP could not predict what future standards would come along and claim more header files and identifiers, it proved much simpler to make the namespace as restrictive as possible unless “-D_HP-UX_SOURCE” is specified. While this has turned into one the most frequently asked of FAQs about HP-UX, at least once you learn this, you don’t have to deal with inconsistencies again. Whereas, had we allowed all non-standard headers to define all non-standard symbols, you’d find identifiers randomly “disappearing
The ANSI standard clearly states what identifiers it reserves, and says the rest are available to you, the programmer. Many “important things” like “ulong” are not specified by ANSI, so ANSI header files are not allowed by the standard to define them. Each standard supported by HP-UX (POSIX1, POSIX2, XPG2, XPG3, XPG4, AES, etc) has its own set of reserved identifiers and header files, and the convention is to require “-D_POSIX_SOURCE” (et al) to enabled their respective namespaces. Since HP could not predict what future standards would come along and claim more header files and identifiers, it proved much simpler to make the namespace as restrictive as possible unless “-D_HPUX_SOURCE” is specified. While this has turned into one the most frequently asked of FAQ’s about HP-UX, at least once you learn this, you don’t have to deal with inconsistencies again. Whereas, had we allowed all non-standard headers to define all non-standard symbols, you’d find identifiers randomly “disappearing”
