[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible bug with grep/sed/tail?
From: |
Pádraig Brady |
Subject: |
Re: Possible bug with grep/sed/tail? |
Date: |
Sun, 30 Nov 2008 17:44:44 +0000 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20071008) |
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.
- Re: Possible bug with grep/sed/tail?, (continued)
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/21
- Re: Possible bug with grep/sed/tail?, Reuben Thomas, 2008/11/21
- Re: Possible bug with grep/sed/tail?, Paolo Bonzini, 2008/11/21
- Re: Possible bug with grep/sed/tail?, Andreas Schwab, 2008/11/21
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/21
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/22
- Re: Possible bug with grep/sed/tail?, Pádraig Brady, 2008/11/22
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/22
- Re: Possible bug with grep/sed/tail?, Brian Dessent, 2008/11/22
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/29
- Re: Possible bug with grep/sed/tail?,
Pádraig Brady <=
- Re: Possible bug with grep/sed/tail?, Pádraig Brady, 2008/11/24
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/24
- Re: Possible bug with grep/sed/tail?, Pádraig Brady, 2008/11/25
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/25
- Re: Possible bug with grep/sed/tail?, Paolo Bonzini, 2008/11/25
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/25
- Re: Possible bug with grep/sed/tail?, Paolo Bonzini, 2008/11/25
- Re: Possible bug with grep/sed/tail?, Pádraig Brady, 2008/11/25
- Re: Possible bug with grep/sed/tail?, Pádraig Brady, 2008/11/25
- Re: Possible bug with grep/sed/tail?, Jim Meyering, 2008/11/25