wohler@sapwdf.UUCP (Bill Wohler) (05/15/91)
folks,
the following example compiles under cc, but not under xlc. why not?
is this brain damage in the way dir.h or standards.h is set up?
the meat of dir.h is only included if _POSIX_SOURCE is defined,
which isn't defined when _ANSI_C_SOURCE is as in the case with
xlc.
does anyone really use xlc?
[wohler@is0002:507]% cat foo.c
#include <dirent.h>
foo()
{
DIR *dirname = opendir("/tmp");
}
[wohler@is0002:508]% cc -c foo.c
[wohler@is0002:509]% xlc -c foo.c
5 | DIR *dirname = opendir("/tmp");
........a....b.........................
a - 1506-045: (S) Undeclared variable.
b - 1506-045: (S) Undeclared variable.
--
--bw
-----
Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler>
Heidelberg Red Barons Ultimate Frisbee Teamkarish@pangea.Stanford.EDU (Chuck Karish) (05/16/91)
In article <2811@sapwdf.UUCP> Bill Wohler <wohler@sap-ag.de> writes: > the following example compiles under cc, but not under xlc. why not? When the C compiler is invoked as 'xlc', it enforces the namespace limitations specified by POSIX.1. No symbols other than those defined by Standard C are visible in the headers unless a feature test macro is #defined or the symbol is in the namespace reserved for the implementation. 'cc' defines '_AIX', which causes '_POSIX_SOURCE' and '_XOPEN_SOURCE' to be set as well. > is this brain damage in the way dir.h or standards.h is set up? > the meat of dir.h is only included if _POSIX_SOURCE is defined, > which isn't defined when _ANSI_C_SOURCE is as in the case with > xlc. That's what the standards require. Declarations of 'DIR' and 'opendir()' would infringe on the namespace that's reserved for the programmer. > does anyone really use xlc? Yes. You do, too; 'cc' actually is an alias for 'xlc'. Calling the compiler as 'xlc' doesn't just change the feature test macros. It changes the semantics of the compiler in many subtle ways to match the C Standard. >[wohler@is0002:507]% cat foo.c >#include <dirent.h> >foo() >{ > DIR *dirname = opendir("/tmp"); >} >[wohler@is0002:508]% cc -c foo.c >[wohler@is0002:509]% xlc -c foo.c > 5 | DIR *dirname = opendir("/tmp"); > ........a....b......................... >a - 1506-045: (S) Undeclared variable. >b - 1506-045: (S) Undeclared variable. >Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler> -- Chuck Karish karish@mindcraft.com (415) 323-9000 karish@forel.stanford.edu
wohler@sapwdf.UUCP (Bill Wohler) (05/17/91)
chuck, you haven't fully answered the question. yes, i know that all the compilers are hard linked to xlc using definitions in /etc/xlc.cfg and other magic internal variables to produce different behavior from the same binary. but 1) would one use xlc to compile code using, for example, <sys/dir.h>? if so, 2) what magic would one have to perform to get DIR and opendir() and so on defined? i'm not too hip on this standards stuff and doing something like defining _POSIX_SOURCE in my makefile gives me the heebie-jeebies. by the way, is it appropriate for mere mortal programmers to define _POSIX_SOURCE, __STDC__, _ANSI_C_SOURCE and so on in ones makefile (obviously if they are not set by built-in macros or <standard.h>)? perhaps there is a document that describes these standards and macros? -- --bw ----- Bill Wohler <wohler@sap-ag.de> <sapwdf!wohler> Heidelberg Red Barons Ultimate Frisbee Team
karish@pangea.Stanford.EDU (Chuck Karish) (05/18/91)
In article <2813@sapwdf.UUCP> Bill Wohler <wohler@sap-ag.de> writes: > 1) would one use xlc to compile code using, for example, <sys/dir.h>? Yes, if one's program is designed to be compiled under Standard C. > if so, 2) what magic would one have to perform to get DIR and opendir() > and so on defined? -D_POSIX_SOURCE makes DIR and opendir() visible. Depending on what's included in "and so on", -D_XOPEN_SOURCE or -D_ALL_SOURCE may be appropriate. >i'm not too hip on this standards stuff and > doing something like defining _POSIX_SOURCE in my makefile gives me > the heebie-jeebies. It shouldn't. It's there to make it easier for you to write portable programs without getting bitten by an extension provided by your system. > by the way, is it appropriate for mere mortal programmers to define > _POSIX_SOURCE, __STDC__, _ANSI_C_SOURCE and so on in ones makefile > (obviously if they are not set by built-in macros or <standard.h>)? __STDC__, no. The others, yes. > perhaps there is a document that describes these standards and > macros? These macros are called "feature test macros". They were invented by the POSIX.1 committee to allow standards to be layered without stepping on one anothers' name spaces. The idea is that if you compile a C program on a POSIX-conforming system that provides Standard C language support and do not have _POSIX_SOURCE #defined, only those symbols specified in the C standard and those in the namespaces reserved for the implementation and for the user are visible in the standard headers. Each feature test macro you #define makes more symbols visible. In your case, you want to make some POSIX symbols visible, so you should #define _POSIX_SOURCE. If you also need some symbols that are #defined in the XPG but not by POSIX.1, #define _XOPEN_SOURCE as well. The POSIX.1 standard describes feature test macros. There are separate documents that describe the POSIX.1 and C standards and the XPG. UniForum publishes several extended brochures that summarize UNIX-related software standards in very general terms. You may also want to take a look at "The POSIX.1 Standard: A Programmer's Guide" by Fred Zlotnick, hot off the press from Benjamin Cummings, ISBN 0-8053-9605-5. O'Reilly has just published a book with similar scope by Don Lewine. If you want to use Standard C but never want to have to worry about feature test macros, make another entry in /etc/xlc.cfg that doesn't #define _ANSI_SOURCE. To see why this will make all AIX symbols visible, take a look at /usr/include/standards.h. -- Chuck Karish karish@mindcraft.com (415) 323-9000 karish@forel.stanford.edu
moody@snap.austin.ibm.com (05/18/91)
In article <2813@sapwdf.UUCP> Bill Wohler <wohler@sap-ag.de> writes:
[everything deleted]
I missed some of this thread, but you may be missing the real reason that this
isn't working. /usr/include/sys/dir.h has a bug in it at line 112. There
is an unterminated comment. This appears in all versions up to 2004. It
is fixed after that. You might try fixing the comment and trying again.
--
James Moody aixnet:moody@moody.austin.ibm.com
Personal Systems Programming Austin VNET:MOODY@AUSVMQ
AIX Field Support - Level 3 internet:moody@aixwiz.austin.ibm.com