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