On Jun 07, 2007, at 06:04:32, Alan Cox wrote:
continuous allocation are part of the API. It's required by POSIX
and provided by Unix since the early days. There are entire code
bases out there which depend on this assumption. Linking with
code like this, before or after the new version controlled symbol
is introduced, will break it.
If your linker is doing its job then you won't be able to link them
together because they have incompatible assumptions. Not exactly
rocket science even if it is done a little differently to the usual
symbol compatibility tests.
No, there is a fundamental problem with "solving" this via linking.
Many programs need the continuous FD allocation space, but then have
tendancies to do things like:
int i;
for (i = 0; i < 1024; i++)
if (i != comm_sock && i != server_sock)
close(i);
Yes I have seen many such programs, it seems to be a pretty standard
idiom.
On the other hand, that makes it completely impossible for libraries
to reliably use FDs behind the application's back; they might get
closed on you at any time without warning. One such library is
glibc; it would really like to be able to use file-descriptors behind
the back of the rest of userspace to implement certain functionality:
http://www.mail-archive.com/[email protected]/
msg163522.html
Likewise there are a massive group of other libraries (especially
user-interface and server related ones) that would really like to
have support for creating file-descriptors without the top-level
application closing them randomly (like several shells seem to).
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
