This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tschwinge/sendmmsg] Add recvmmsg and sendmmsg to the generic glibc API


> sendmmsg is called from __libc_res_nsend which is called from
> __libc_res_nquery and res_nsend, the latter is declared in
> resolv/resolv.h, so would that fulfil the »standard-specified or
> traditional name space« and not »in GNU extension functions«
> requirements?

Yes, that's the traditional BSD name space (what you get with -D_BSD_SOURCE
but no -D_GNU_SOURCE).  So it should ideally not refer to GNU extensions.
Being traditional rather than standard, it's really up to us to say when
we care, but my inclination is to care by default.

> Hmm, on the other hand, libresolv seems to use both kinds of symbol
> references:
> 
>     $ readelf --dyn-syms resolv/libresolv.so
>     
>     Symbol table '.dynsym' contains 170 entries:
>        Num:    Value  Size Type    Bind   Vis      Ndx Name
>          0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
>          1: 00000000     0 FUNC    GLOBAL DEFAULT  UND __ctype_toupper_loc@GLIBC_2.3 (7)
>          2: 00000000     0 FUNC    GLOBAL DEFAULT  UND setbuf@GLIBC_2.0 (8)
>          3: 00000000     0 FUNC    GLOBAL DEFAULT  UND __fcntl@GLIBC_2.0 (8)
>     [...]
> 
> So, which is it?

setbuf and fcntl are both in the core POSIX.1 name space (setbuf via ISO C)
and so either kind of call is fine from libresolv.  

In libc code, it never hurts to use the internal names just so as not to
have to keep track of which name space your caller is in.  Also note that a
single DSO can two functions in different name space categories.  If say
there is a standard function and a GNU extension function, if the GNU
extension function is not called by any implementation code reached from a
standard name space function, then it doesn't matter whether it uses other
functions outside that name space.  If an application using only the
standard name space redefines such other functions, then it won't ever be
able to notice that the GNU extension function it doesn't call would behave
differently.

> The rationale being that in the latter case we're violating the
> standards' name space rules anyway (with the new symbols we add as GNU
> extensions), so in this case adding an additional sendmmsg symbol doesn't
> hurt?

Yes.  More precisely, we treat our nonstandard feature-test macro name
spaces (_BSD_SOURCE, _GNU_SOURCE) as if they were standards, so their
superset relationship to the standard name spaces is like that of a later
POSIX.1 version with an earlier one or with ISO C.  sendmmsg is now in the
GNU name space, so the rest of the GNU name space referring to it is fine.

> After having gone through the mildly brain-twisting update of
> sysdeps/unix/sysv/linux/*sendmmsg.*, I decided to convert recvmmsg in the
> same turn.  If you don't want that, I can back it out.

Let's not add any symbols we don't actually need.

> > All files using stub_warning need #include <stub-tag.h>.
> 
> Have been missing from sysdeps/unix/sysv/linux/*mmsg.c.  ;-)

Please send a separate fix for that.  The failure mode is missing __stub_*
defines in the installed <gnu/stubs.h> file (here only when compiling with
kernel headers that don't define __NR_sendmmsg et al).

> OK.  Though, that then requires some manual effort if the patch is also
> going to be published as a Git branch.

See the git-show-gnu script I posted here a while back.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]