xlc and <sys/dir.h> brain damage

xlc and <sys/dir.h> brain damage

Post by Bill Wohl » Thu, 16 May 1991 22:23:46



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?


#include <dirent.h>
foo()
{
        DIR *dirname = opendir("/tmp");

Quote:}



        5 |         DIR *dirname = opendir("/tmp");
            ........a....b.........................
a - 1506-045: (S) Undeclared variable.
b - 1506-045: (S) Undeclared variable.

--
                                                --bw
-----

Heidelberg Red Barons Ultimate Frisbee Team

 
 
 

xlc and <sys/dir.h> brain damage

Post by Chuck Kari » Fri, 17 May 1991 09:30:51



>  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.

Quote:>  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.

Quote:>  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.


>#include <dirent.h>
>foo()
>{
>        DIR *dirname = opendir("/tmp");
>}


>        5 |         DIR *dirname = opendir("/tmp");
>            ........a....b.........................
>a - 1506-045: (S) Undeclared variable.
>b - 1506-045: (S) Undeclared variable.


--




 
 
 

xlc and <sys/dir.h> brain damage

Post by Bill Wohl » Sat, 18 May 1991 23:49:19


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
-----

Heidelberg Red Barons Ultimate Frisbee Team

 
 
 

xlc and <sys/dir.h> brain damage

Post by Chuck Kari » Sun, 19 May 1991 04:58:46



>  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.

Quote:>  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.

Quote:>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.

Quote:>  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.

Quote:>  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.
--



 
 
 

xlc and <sys/dir.h> brain damage

Post by mo.. » Sun, 19 May 1991 06:01:58


[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.

--



 
 
 

1. include files <sys/ipc.h> and <sys/shm.h>

Hello,
        I'm in the process of getting linux up and going and have just
installed the SLS distrabution (from sunsite).  Anyways I have downloaded
the latest dosemu0.49 and am trying to compile it.  Unfortunately it
expects two files: <sys/ipc.h> and <sys/shm.h>, where can I get these and
any other misc include files that I may need? (They were not obviously
located at sunsite).
        Also I have X running with a microsoft 2 button mouse, how do I
emulate the thrid button?

Hoa Ton-That

PS.  LINUX is much more reliable than i'd hoped :)
--

2. Help w/ rc.S file

3. #define NOERROR in <sys/stream.h> and <arpa/nameser.h>

4. About chmod ug+s command

5. Kernel include files <sys/socket.h> and <linux/in.h>

6. /dev/null directory analog?

7. <sys/dir.h> bugged in libc 2.11c distribution

8. Have POP-3 Service up but it wont accept connections

9. #include <asm/bitops.h> -> #include <linux/bitops.h>

10. 1.3.98: <linux/if_arp.h> needs to include <linux/netdevice.h>

11. Include <linux/stddef.h> in <linux/list.h>

12. POSIX, ANSI standards and <sys/types.h>

13. <sys/un.h>