This is the mail archive of the 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]


> I think current __FD_ELT is right implemenation. It only fail when passed argument is not
> dynamic allocated.

Ugh. I was wrong. Current __FD_ELT is not correct. I received a bug
report this feature makes invalid program abort when running ruby on

Because Ruby uses howmany macro and allocates fd_set from heap and Ubuntu enable
_FORTIFY_SOURCE=2 by default.

There is unfortunate conflict here. glibc __FD_ELT check POSIX
validness, not Linux validness. Linux support >1024 fd number since
Linux 2.2.12 (about 15years ago).

As far as I skimmed Debian Code Search, su, rsyslog, ssh and other
several BSD derived
software use the same technique. I think the current situation is
dangerous and I believe
we shouldn't break existing software in the real world.

Side note: POSIX and Other OSs status

 > [EINVAL]The nfds argument is less than 0 or greater than FD_SETSIZE.

    Ignore POSIX and support allocation fd_set from heap.

Mac OS X:
    is not defined. i.e. every practical applications turn on

    select return EINVAL when >FD_SETSIZE. Instead, provide
    i.e. applications do #define select(n, r, w, e, t)
select_large_fdset((n), (r), (w), (e), (t)).

So, there are several options.

1. only turn on __FD_ELT check when running on hurd.
2. only turn on __FD_ELT check when defined some specific macro. (e.g.
likes darwin,
    but disable by default)
2-2. make FORTIFY_SOURCE variant and check POSIX compliance if enabled.
3. provide select_large_fdset() likes solaris. (I strongly don't
recommend. all application
    need to modify and recompilation)

What do you think?

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