Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: why is this in h2ph
Message-ID: <11232@jpl-devvax.JPL.NASA.GOV>
Date: 30 Jan 91 18:04:32 GMT
References: <1991Jan8.073648.7186@uvaarpa.Virginia.EDU> <11216@jpl-devvax.JPL.NASA.GOV> <120572@uunet.UU.NET>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 66

In article <120572@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
: In article <11216@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
: >h2ph doesn't attempt to define %sizeof, however.  Tom's h2pl/mksizes
: >program will try to do that for you.
: >
: >But it's all jiggery-pokery.  Hopefully we'll get something based on
: >C's debugging stabs that will be a bit more robust.
: 
: How about predefining %sizeof for us Larry! A reasonable approximation
: might be, `if you have to mess with it in perl's C code, it then
: a user might want to know about it as well'.

Except that most of those structures are already provided in Perl built-ins.
It's the ones that aren't built-ins that you end up wanting, like you find
in utmp.h, or a.out.h, or X11/Xproto.h.  :-)

: >The whole "include" paradigm is somewhat undisciplined, however, even
: >in C.  There's probably several research projects in there.
: 
: I don't think so. The solution is simple really. I could kill
: the ANSI C committe for failing to include the #require statement
: or just changing the meaning of #include to a require.
: 
: I applaud you for your choice.

Thanks.

The primary thing that bothers me about C inclusions is that it's impossible
to come up with a standard list of symbols and definitions.  I tried writing
a program that would go out and examine all the C header files and attempt
to determine the dependencies between them so that I could automatically
write a C program that could be compiled containing all the structure
definitions that Perl might be interested in.  This turns out to be a
tough AI problem, because there are contradictions, both intra-system
and inter-system, and the information to resolve the contradictions isn't
in the includee, but in the includer, which is unknowable.  

A more immediate problem in the C include scheme is that you can't
determine at compile time whether a given include file is available, and
it's a fatal error if it's not.

: I read a style guide from one of the Bell guys (Pike?). One of
: his prohibitions was include files including other include files.

Figures.

: The inclusion control is done at the wrong place; inside the file rather
: than around the #include. It is not uncommon for things like <sys/types>
: to be included ten (and ignored nine) times in a single compilation.

So for efficiency they outlaw nested includes.  But just as unspecified
dependencies will eventually bite you in a Makefile, so too they'll eventually
bite you in header files.  All header files should include all their
dependencies.  Fortunately, most C preprocessors are capable of skipping
unwanted text fairly efficiently.

You'll no doubt go and look at my sources, and discover that my header
files don't include all their dependencies.  And they can't, because
not everyone's header files are #ifdef'ed to avoid multiple inclusion yet.
Maybe someday...

: 	print unsort split(//,"   ,Jaaceeehhklnoprrrsttu")

I think I laughed longer than Randal did.  That was, um, choice.

Larry