On Tue, Nov 13, 2018 at 10:44:24AM +1030, Alan Modra wrote:
> On Mon, Nov 12, 2018 at 01:44:08PM -0600, Bill Schmidt wrote:
> > On 11/6/18 11:37 PM, Alan Modra wrote:
> > > + fun, "l" + sibcall);
> >
> > It's not at all clear to me what {"l" + sibcall} is doing here.
>
> It's an ancient C programmer's trick, from the days when most
> compilers didn't optimize too well. I think I found it first in the
> nethack sources. :-)
>
> > Whatever it is, it's clever enough that it warrants a comment... :-)
> > Does adding "l" to false result in the null string? Is that
> > standard?
>
> "l" results in a "const char*" pointing at 0x6c,0 bytes in memory
> (assuming ascii). Adding "true" to that implicitly converts "true" to
> 1 and thus a "const char*" pointing at a NUL byte. All completely
> standard, even in that new fangled C++ thingy.
>
> A comment is as much needed as count++; needs /* add one to count. */.
> If it bothers people I'll write: sibcall ? "" : "l".
That is nicer, esp. if you can propagate it a bit, simplify the separate
cases.
> Hah, even the latest gcc doesn't optimize the conditional expression
> down to "l" + sibcall. Check out the code generated for
>
> const char *
> f1 (bool x)
> {
> return "a" + x;
> }
>
> const char *
> f2 (bool x)
> {
> return x ? "" : "b";
> }
It also doesn't do the opposite: it doesn't optimise
const char *f(_Bool x) { fputs("x" + x, stdout); }
(if x is true this does nothing).
> Segher, would you like me to repost the series with accumulated fixes,
> I mean before you review the rest of the series?
Yes please.
Segher
