Re: Possible bug with grep/sed/tail?

[Pádraig Brady]

Jim Meyering wrote:
> Brian Dessent <address@hidden> wrote:
>> Jim Meyering wrote:
>>>   local setvbuf='__attribute__ ((constructor)) void
>>>     f () { setvbuf (stdout, NULL, _IOLBF, 0); }'
>>>   echo "$setvbuf" | gcc -s -include stdio.h -x c - -fPIC -shared \
>>>                         -o "$line_buffer_so"
>> Note that I named the function 'f()' for brevity in the example, but for
>> a general solution I worry that it should have a name that cannot clash
>> with any other global symbol in the program or any of its libraries.
>> One way of achieving this is to put it in an anonymous namespace, which
>> obliges the compiler to give it a guaranteed-unique name:
>>
>>   local setvbuf='namespace { __attribute__ ((constructor)) void
>>     f () { setvbuf (stdout, NULL, _IOLBF, 0); } }'
>>   echo "$setvbuf" | gcc -s -include stdio.h -x c++ - -fPIC -shared \
>>                         -o "$line_buffer_so"
> 
> Nice.
> For my personal use, relying on g++ is fine.
> But if we end up adding a tool like Pádraig's proposed "stdbuf",
> I am inclined to use only C.  Why?  It's not that C++ support isn't
> mature, it's just that adding a requirement in _coreutils_ (even if
> only for this one program) on not just LD_PRELOAD but also on C++...
> seems like opening pandora's box.  Any target system must already
> have LD_PRELOAD support, so that may help by eliminating some of
> the older candidates.

Yep, this is what I'm doing :)
I know C++ quite well actually. Well enough to be very wary of it.
__attribute__ ((constructor)) is available since gcc 2.95.1 at least.
(10 years).

> 
> Guaranteed namespace anonymity would be nice, but initially it will be
> ok to sacrifice that, as long as we choose a function name that is long
> and random.

Yep, the function name is not user visible so we can give it
something sufficiently unique.

> 
> At least for starters, I'd rather build the new program only when gcc
> is available with __attribute__((constructor)) support.  Or some other
> C compiler, as long as we know how to do the same things with it.
> Keep it simple.  This is the *GNU* coreutils package, after all,
> so it's ok if certain extra-value features are initially available
> only on systems with GNU tools.

cheers,
Pádraig.