Re: libctf: make it compile for old glibc

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Sun, 14 Jul 2019, Nick Alcock wrote:

> On 11 Jul 2019, Hans-Peter Nilsson spake thusly:
> > But objdump should be able to decode CTF generated by outside
> > producers, right?
>
> Yes, but right now there are only two: libctf and GCC. So it's hard to
> test it against a third producer, when no third exists :) though I'd
> agree that when a third *does* exist, we should generate some CTF with
> it and make sure that at the very least we can read it in with libctf.

The posted links made me think CTF was in heavy use somewhere in
BSD-land and for some Solaris thingy since years already (dtrace)?

Is it, but for an incompatible version?  If so, supporting the
pre-existing versions (at least reading them) will probably be
requested sooner rather than later.

> >> > BTW, what's up with the ((x)) seen in the context?  Worrying about
> >> > buggy library implementations not parenthesizing arguments?
> >>
> >> Pure paranoia, yes :) it's easier to add one layer of brackets than
> >> worry about every use of the macros. Always-parenthesised args are just
> >> safer. :)
> >
> > Sounds better than an editing mistake. :)  Otherwise we'd do
> > that for all function-like system thingies that might be macros.
>
> Doesn't everyone do that sort of thing in macro definitions? I know I
> feel guilty whenever I forget.

Not really; this is sufficiently different to the parentheses in
e.g. "#define SQUARE(x) ((x) * (x))" which should be in the
memory of everyones fingertips.

Writing it as "#define htole64(x) bswap_64 (x)" should be
sufficient; you should not worry about definitions (system
headers, glibc) missing to parenthesize any macro arguments.

A "#define htole64(x) bswap_64 ((x))" (without a known buggy
version pointed out in a comment above the definition) just
causes confusion for the reader, QED.  I should add that's IMHO,
but I've never seen that "distrust" in use of macros around
here.  Even if so, it's missing a set of parentheses. ;-)

brgds, H-P