Marc Christiansen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> Hmm, when the second argument is omitted, the system call looks like:
> >>
> >> getservbyname("daytime", NULL);
> >>
> >> Based on "man getservbyname" on my Linux PC, that should give
> >> the behaviour we
> >> want - any protocol will match.
> >>
> >> However:
> >>
> >> Linux 2.6.4-52-default (Suse 9.1)
> >> Glibc 2.3.3
> >> gcc 3.3.3
> >>
> >> So it may be that your older platform doesn't have this
> >> behaviour - I'd be very
> >> interested in what 'man getservbyname' has to say.
> >
> > Just took a look at the man page for getservbyname on this
> > system and it doesn't mention passing NULL as the second
> > argument. The pertinents: ;-)
> >
> > Linux kernel 2.6.10
> > Glibc 2.2.5
> > gcc 2.95.3
> Just to confuse the matter more, on my system the man page mentions
> passing NULL as the second argument and it works. Alas:
> SuSE 7.3
> Kernel 2.4.29 (vanilla)
> Glibc 2.2.4 (older than yours)
> gcc 2.95.3
> > I'd say your probably right about there being a difference
> > in the behaviour of getservbyname between libc 2.2.5 and
> > and libc-2.3.3 given the differences in man pages and
> > observed return values. I'll try and compare the libcs'
> > getservbyname codes and let you know a little later in
> > the day.
> >
> > I wonder if the developers wanted to tie the python source
> > code so closely to a glibc version and possibly gnu-libc
> > specific?
> Perhaps SuSE did patch the glibc...
> Saluton
> Marc
hey Marc
Oh man, not another problem that's just happening to
me, again. :-)
We all are still talking about python 2.4 aren't we? I'm
really running out of options on this.
My manual page for getservbyname is dated "22 April 1996"
and i think that it wasn't installed by glibc-2.2.5. The
info page for getservbyname which was installed by 2.2.5
doesn't mention being able to pass NULL as a 'PROTO'
argument.
As for my saying above that i would take a look at the
libcs' code for getservbyname, well, let's just say
i won't be bantering about that idea so readily anytime
soon. :-)
What i believe happens in glibc-2.3.3 is that getservbyname
is generated by two files: inet/getsrvbynm.c which contains
a number of '#define's that then '#include's the file
nss/getXXbyYY.c which is sort of a template function that
the '#define's fill out. If your use to reading it
nss/getXXbyYY.c probably is easy reading, but, for ego's sake,
let's just say that i'm not use to reading it. There's
also getsrvbynm_r.c and getXXbyYY_r.c for the reentrant
versions of getservbyname plus some references to nss and
nis versions of getservbyname. Of course its also possilble
that where i said "What i believe happens" at the beginning
of this paragraph could be read as "I'm confused about what
happens" and i don't mean that as critic of glibc.
Marc, it is possible that there was a change between
glibc-2.2.4 and 2.2.5 that would account for the
difference in behaviour. I think i'll write a little
test program in C to check out getservbyname's return
values in a little more controled environment. I'll
post the results tomorrow.
pete jordan
x2164 mailcity com
--
............
--
http://mail.python.org/mailman/listinfo/python-list
