chris@bwilab3.UUCP (Chris Curtin) (12/20/90)
Hello,
I am trying to write ANSI C programs that use calls to UN*X specific
functions. When compiling in ANSI mode i.e. -Aa the compiler cannot find
function prototypes and definitions in some header files. In non ANSI mode
the definitions are found.
I was told to resolve this problem by #defining _HPUX_SOURCE. This solves
the problem of the compiler not finding the prototypes but raises some
questions about what it does. I was also told, by someone else, that the
_HPUX_SOURCE tells the compiler that I am compiling kernel code. Is this
true? Is there a better way to get access to the routines than _HPUX_SOURCE?
What problems am I opening up by using this? (i.e. am I allowing access to
kernel routines that I am not supposed to?)
Info about our system:
HP 9000-835
HP-UX 7.0
HP C Compiler A.07.10
Also, i have noticed that the semun union is not defined in the <sys/sem.h>
header file. We had to define our own to be able to use semaphores in ANSI
mode.
The header files that did not include the proper defs without _HPUX_SOPURCE,
that I used are:
<sys/sem.h>
<fcntl.h>
<stdio.h> and
<sys/types.h>
- These are the ones that I have found and I am sure that the others have the
same problems.
Any suggestions or comments are welcome.
Thanks
Chris
--
Christopher M. Curtin
Bradley Ward Inc.
Atlanta Ga.
{ ..!gatech!galbp!bwilab3!chris}mev@hpfcso.HP.COM (Mike Vermeulen) (12/21/90)
> I was told to resolve this problem by #defining _HPUX_SOURCE. This solves > the problem of the compiler not finding the prototypes but raises some > questions about what it does. I was also told, by someone else, that the > _HPUX_SOURCE tells the compiler that I am compiling kernel code. Is this > true? Is there a better way to get access to the routines than _HPUX_SOURCE? > What problems am I opening up by using this? (i.e. am I allowing access to > kernel routines that I am not supposed to?) _HPUX_SOURCE tells the compiler to use the same namespace as when compiling in compatability mode (-Ac). It has nothing to do with whether the code is kernel code or not. For background, here is the reason for needing _HPUX_SOURCE: The ANSI C standard specifies exactly which symbols are reserved by the implementation and which ones are available for the user. For example, while the symbol "open" is a UNIX* system call, this name is not reserved by the standard. Thus programs compiling with ANSI C should have the ability to define their own routine named "open" and not have it conflict with the library/system routine. When compiling with -Aa you get a complete ANSI C conformant compile including namespace. There are additional standards that specify additional names. There are predefines that may be used to get these symbols. For example, the POSIX standard specifies that the namespace for the POSIX namespace can be gotten by placing a #define _POSIX_SOURCE prior to including any headers. The names for XOPEN can be gotten with the symbol _XOPEN_SOURCE. Thus _HPUX_SOURCE gets you the complete polluted namespace that is available in compatability mode. --mev disclaimer: not an official response.
shankar@hpclscu.HP.COM (Shankar Unni) (12/22/90)
> I am trying to write ANSI C programs that use calls to UN*X specific > functions. When compiling in ANSI mode i.e. -Aa the compiler cannot find > function prototypes and definitions in some header files. In non ANSI mode > the definitions are found. > > I was told to resolve this problem by #defining _HPUX_SOURCE. This solves > the problem of the compiler not finding the prototypes but raises some > questions about what it does. I was also told, by someone else, that the > _HPUX_SOURCE tells the compiler that I am compiling kernel code. Is this > true? Is there a better way to get access to the routines than _HPUX_SOURCE? > What problems am I opening up by using this? (i.e. am I allowing access to > kernel routines that I am not supposed to?) The ANSI C standard mandates the contents of certain header files (the "magnificent 15", including <stdio.h>, <math.h>, <stdlib.h>, etc). These files can, in a *strictly conforming* ANSI C implementation, only contain those identifiers that the ANSI C standard says that it can. The -Aa flag on HP-UX is supposed to make the C compiler present a fully conformant ANSI C implementation, which is why it suddenly hides all the non-ANSI symbols under _HPUX_SOURCE. The convention adopted by the Unix-ish standards (which *also* have name-space pollution constraints) is to specify that an ANSI C compiler which defines a certain magic define (-D...) will get a name space that conforms to that standard: -D_POSIX_SOURCE: Posix 1003.2 -D_XOPEN_SOURCE: X/Open In the same vein: -D_HPUX_SOURCE: everything on HP-UX. _HPUX_SOURCE is a superset of _POSIX_SOURCE, which is a superset of the ANSI C name space. (By the way, in "compatibility mode", the -D_HPUX_SOURCE is defined automatically for you, something we cannot do in -Aa mode, because it will break ANSI C conformance). ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar