Hi,
there are 2 reasons for using numbers:
1. the socket() function has integer arguments, see 'man
socket'
2. Since APL nas no #define facility, names would be
strings and those
would cause unneccessary computational overhead. And the names
would
be more readable but proprietary. And often one function returns
an integer that
is then used by another function. Having an intermediate string
representation
of these integers is cumbersome and difficult to maintain.
/// Jürgen
On 04/17/2015 05:13 AM, Christian
Robert wrote:
If
this ok for you it's ok for me too.
They are standardized have not changed in the last 35 years to my
knowledge,
and this is a reason "+" to include thems as strings as
parameters to ease the programmer task.
nevertheless, you do as you want.
Xtian.
ps: having thems in ".so" as strings get the advantage to not
accept an "AF_INET" as a value to an "IPPROTP_TCP" parameter.
On 2015-04-16 22:59, Elias Mårtenson wrote:
On 17 April 2015 at 10:55, Christian
Robert <address@hidden
<mailto:address@hidden>> wrote:
I though about that too (defining AF_INET, AF_UNIX,
SOCK_STREAM, SOCK_DGRAM, IPPROTO_TCP, IPPROTO_UDP, IPPROTO_RAW,
and such (tenths more)),
but I *still* think it should be in the ".so" and not in
the )lib 5 "FILE_IO"
If the actual values for these constants are not standardised
(i.e. they can change on different operating systems) then of
course, they need to be in the .so. As for the particular
values, I have to admit that I have no idea if they ever change.
That said, I'd still prefer variables rather than strings. The
values of the variables could be retrieved from a call into the
.so and initialised on library load though.
|