Re: [PATCH 2/5] __FD_ELT: Implement correct buffer overflow check

[KOSAKI Motohiro <kosaki.motohiro@gmail.com>]

>> +     ? __fdelt_buffer_warn(__d, __bos0 (s))                          \
>
> Space between function and bracket e.g. foo () not foo().

ah, ok.

>
>> +     : __fdelt_buffer_chk(__d, __bos0 (s))                           \
>> +      : __d / __NFDBITS;                                             \
>
> I'm not happy that this isn't very conservative.
>
> If __bos0 fails should we fall back to static FD_SETSIZE checking
> e.g. "__fdelt_buffer_warn (__d, FD_SETSIZE)"?
>
> It seems that that would be better than no checking.

Hmm.. This doesn't cross my mind. All other buffer boundary checks
of _FORTIFY_SOURCE fall back no checking.  compiler may fails to
determine a right buffer size in various reasons. at that time, I don't
want to kill innocent applications.

> I know why you want to fall back to no check, because that
> way you don't require any kind of new flag to disable the
> check in the event it triggers when you don't want it to
> (when __bos0 fails).

If you like flag, I'm not putting objection. but if making flag, a lot
of libraries need
to turn on "no check" mode because when a buffer is allocated from applications,
library code can't know a buffer size at least at compile time.


> Does compiling ruby (or similar code) with this header
> result in calls to __fdelt_buffer_warn or __fdelt_buffer_chk?

Unfortunately, No. __builtin_object_size() require compiler know the
buffer size.
In the other words, it doesn't work if an allocate function and
FD_{SET,CLR} functions
doesn't exist in the same place. This is the same limitation with
other string buffer
overflow checks.