socket related constants
Leopold Toetsch
typical socket ocde currently looks a bit unfriendly due to magic constants,
e.g.
socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp
I'd like to have symbolic constants for all that stuff:
socket sock .PF_INET, .SOCK_STREAM, .PROTO_tcp
Appended is a C snippet, which produces such constants[1]. It's incomplete and
not integegrated in Configure/make at all, but maybe it is a starting point.
Q: is there a better option to generate these constants?
leo
[1] # or such
$ cc -DUNIX -o sock_gen -Wall sock_gen.c && ./sock_gen >
runtime/parrot/include/socket.pasm
Chromatic
> typical socket ocde currently looks a bit unfriendly due to magic
> constants, e.g.
>
> socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp
>
> I'd like to have symbolic constants for all that stuff:
>
> socket sock .PF_INET, .SOCK_STREAM, .PROTO_tcp
>
> Appended is a C snippet, which produces such constants[1]. It's incomplete
> and not integegrated in Configure/make at all, but maybe it is a starting
> point.
>
> Q: is there a better option to generate these constants?
It'd sure be nice to have a PGE/TGE parser that could understand C header
files and generate static NCI code. (That is, don't make the FFI mistake of
parsing the header files every time you run the program that uses them.)
-- c
Kevin Tew
Its a start at a PGE grammar for C99
Kevin
Leopold Toetsch
> check out the newly added languages/c99
> Its a start at a PGE grammar for C99
Whut? Whut?
Whutzeesayin'?
just 3 lines of svn log messages - and I've missed these ;-)
++tewk
leo
Nicholas Clark
> Hi,
>
> typical socket ocde currently looks a bit unfriendly due to magic constants,
> e.g.
>
> socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp
>
> I'd like to have symbolic constants for all that stuff:
>
> socket sock .PF_INET, .SOCK_STREAM, .PROTO_tcp
>
> Appended is a C snippet, which produces such constants[1]. It's incomplete and
> not integegrated in Configure/make at all, but maybe it is a starting point.
>
> Q: is there a better option to generate these constants?
I can't give an exact answer, but...
Perl 5 has gone through several generations of "how to do constants"
There are two problems to be solved
1: Parsing C header files and identifying what are actually constants
(might be #ifdefs, might be enums, the value of an #ifdef may be an
expression that happens to evaluate to a constant)
(For shipped libraries the alternative seems to end up being listing all
the constants you expect to see, the union of constants in all the
variants of that header across operating systems/compiler runtimes)
2: Injecting identified constants into Perl (here Parrot) appropriately
With Perl 5.10 we should be at the point of actually having constants that
are both memory efficient and inline into code at compile time.
However, step 2 is easier for Perl because we're not trying to do portable
bytecode. Some constants, (such as *most* of the socket constants, but I think
not all) are defined in RFCs, so can be baked into bytecode at compile time.
But other constants (such as POSIX limits) are per system, so a complete
solution needs a way of knowing how to defer baking those constants until
load time. Or maybe it doesn't call them "constant" as far as bytecode
interpretation goes, but any JIT or AOT can see that they are, and treat them
accordingly.
Nicholas Clark
Joshua Hoblitt
>
> However, step 2 is easier for Perl because we're not trying to do portable
> bytecode. Some constants, (such as *most* of the socket constants, but I think
> not all) are defined in RFCs, so can be baked into bytecode at compile time.
> But other constants (such as POSIX limits) are per system, so a complete
> solution needs a way of knowing how to defer baking those constants until
> load time. Or maybe it doesn't call them "constant" as far as bytecode
> interpretation goes, but any JIT or AOT can see that they are, and treat them
> accordingly.
Mentioning sockets got me thinking about APR... Has anyone seriously
looked at using it for doing portable I/O?
-J
--