marc@athena.mit.edu (Marc Horowitz) (01/08/91)
I don't think I've found another unintentional feature this time :-)
In h2ph, there is this piece of code:
elsif ($isatype{$id}) {
$new .= "'$id'";
}
What is it good for? The only time I've ever seen it match is when
there is a cast in a #define. For example:
#define lettera ((char) 65)
becomes
sub lettera {(('char') 65);}
This causes perl to have fits, of course.
Is there a reason that one of the matches in expr can't look like
s/^\(((un)?signed\s+)?[_a-zA-Z]\w*\)//;
If I understand h2ph correctly, this will have the useful effect of
just stripping casts from #defines. Since perl doesn't do any kind of
real types, if you're casting into something besides char, short, int,
or long you're likely to lose anyway, so an error from the .ph file is
probably appropriate. Basically, the intent is that casts, which are
fairly common, not cause h2ph to lose. The subsidiary intent is that
I not have to edit a lot of .ph files :-)
Comments?
Marclwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (01/30/91)
In article <1991Jan8.073648.7186@uvaarpa.Virginia.EDU> marc@mit.edu writes:
: In h2ph, there is this piece of code:
:
: elsif ($isatype{$id}) {
: $new .= "'$id'";
: }
:
: What is it good for? The only time I've ever seen it match is when
: there is a cast in a #define. For example:
:
: #define lettera ((char) 65)
:
: becomes
:
: sub lettera {(('char') 65);}
:
: This causes perl to have fits, of course.
:
: Is there a reason that one of the matches in expr can't look like
:
: s/^\(((un)?signed\s+)?[_a-zA-Z]\w*\)//;
:
: If I understand h2ph correctly, this will have the useful effect of
: just stripping casts from #defines. Since perl doesn't do any kind of
: real types, if you're casting into something besides char, short, int,
: or long you're likely to lose anyway, so an error from the .ph file is
: probably appropriate. Basically, the intent is that casts, which are
: fairly common, not cause h2ph to lose. The subsidiary intent is that
: I not have to edit a lot of .ph files :-)
The lettera definition is unlikely to do you much good in Perl, so the
correct way for h2ph to protect it would be to enclose it in an eval.
The intent of the $isatype{} code is to translate sizeof() reasonably,
since many implementations of ioctl encode the size of the structure to
be passed in the second argument. Thus
sizeof(int)
turns into
$sizeof{'int'}
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.
The whole "include" paradigm is somewhat undisciplined, however, even
in C. There's probably several research projects in there.
Larryrbj@uunet.UU.NET (Root Boy Jim) (01/30/91)
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'. >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. I read a style guide from one of the Bell guys (Pike?). One of his prohibitions was include files including other include files. 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. >Larry print unsort split(//," ,Jaaceeehhklnoprrrsttu") -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
tchrist@convex.COM (Tom Christiansen) (01/30/91)
From the keyboard of rbj@uunet.UU.NET (Root Boy Jim):
: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'.
If you jiggle h2pl/{getioctlsizes,mksizes} about, you should get
enough of what you need to create a sizeof.ph file.
--tom
--
"Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now
he can finally have the whole O/S built-in to his editor like he
always wanted!" --me (Tom Christiansen <tchrist@convex.com>)lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (01/31/91)
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
marc@athena.mit.edu (Marc Horowitz) (02/01/91)
I said: |> : #define lettera ((char) 65) |> : |> : becomes |> : |> : sub lettera {(('char') 65);} Larry responds |> The lettera definition is unlikely to do you much good in Perl, so the |> correct way for h2ph to protect it would be to enclose it in an eval. well, what I'd like to see output is sub lettera { 65; } That would let me use &lettera in the same way the #define was intended to be used. |> 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'. Yes. And while you're at it, instead of kludging sizeof, special case it: s/^sizeof\(([^\)])\)/$sizeof{'$1'}/; Or something like that. That way, it would be obvious what was going on, and if I had sizeof(struct foobar) in my .h file, I could add $sizeof{'struct foobar'} = 42; somewhere before (or in) the .ph file and make it do what I want. I guess this is something else to add to my todo list. Root Boy Jim says: |> I read a style guide from one of the Bell guys (Pike?). One of |> his prohibitions was include files including other include files. |> 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. This is completely off subject, but I need to ask. Do you agree with this restriction? I believe inclusion control should be transparent to the includer. So the right place to do it is in cpp, but since ANSI blew it, I think enclosing the entire include file in #ifndef/#endif is the right solution. My justification is that if I #include <X11/Intrinsic.h>, I shouldn't need to track down the 17 other files it includes recursively. And I'd rather not think about making it do the right thing under all the different flavors of Unix I'd like my code to compile under. If you agree with me that Pike is completely off his rocker on this one, then ignore the previous paragraph :-) Marc