Re: Possible bug with grep/sed/tail?

[Brian Dessent]

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"

> # test with this:
> # (while :; do printf 'x\ny\n'; sleep 1; done) |line-buffer grep x

Is that really a valid test?  Doesn't the stdout of grep need to be a
pipe?

> > Of course this solution depends on gcc and LD_PRELOAD etc.
> 
> The mixed blessing of shared libraries...

Well, __attribute__((constructor)) is gcc-specific but it was another
shorthand used for brevity to squeeze things into one line.  The ctor
could however just as well be implemented in plain ISO C++.  Naturally
the specific set of required options to produce a shared library does
tend to be compiler specific though.

I'd be more concerned about the portability of LD_PRELOAD, which tends
to be a feature of ELF systems.  Cygwin does provide an emulation of
LD_PRELOAD however, so the example at least does work there as well,
modulo s/-fPIC// and s/.so/.dll/.

Brian