<div dir="ltr">Thank you, both.  I'll return to the fold and use NULL, as seems right and proper.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 16, 2016 at 7:12 AM David Gibson <<a href="mailto:david@gibson.dropbear.id.au">david@gibson.dropbear.id.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jun 14, 2016 at 01:45:10PM +0930, Paul 'Rusty' Russell wrote:<br>
> Dan Good <<a href="mailto:dan@dancancode.com" target="_blank">dan@dancancode.com</a>> writes:<br>
> > Hi David,<br>
> ><br>
> > I'm back home in front of a real keyboard, and want to follow up with you<br>
> > about your patches.  I must admit that my usual practice is to use NULL,<br>
> > and not 0.  Around the time I wrote altstack I had recently read Jen<br>
> > Gustedt's book, Modern C.  In it, he makes the point that NULL hides more<br>
> > than it clarifies (see section 11.7).<br>
><br>
> (I don't really care: your code, your style).  But...<br>
><br>
> He is so horrifically wrong, it's amazing.<br>
><br>
> Section 7.17 is loosened from ANSI C which said NULL was 0, presumably<br>
> to *allow* compilers to avoid the varargs issue.  A compiler *could* do<br>
> insane shit to make that problem even worse, but you would never use<br>
> such a compiler.  There are other legal-but-insane things a compiler can<br>
> do, too, and the answer is the same; real code won't work, nobody else<br>
> cares.<br>
><br>
> OTOH, using 0 in place of NULL makes for much more potential type order<br>
> confusion.  Not to mention confusing every damn C programmer on the<br>
> planet.<br>
<br>
Yeah.  I can kind of see the hint of a good idea in those articles,<br>
but on balance they're really not convincing.  Basically, as Rusty<br>
says, matching the conventions of the huge bulk of existing C code<br>
outweighs the value of working with a compiler/library that has gone<br>
out of its way to implement this stupidly.<br>
<br>
> Note, I also assume NULL is all zero-bits,<br>
<br>
I try to avoid that one, although I can't be sure I always have - I'm<br>
not sure, but I think one of the s390 variants might break this.<br>
<br>
> that size_t can hold a<br>
> ptrdiff_t,<br>
<br>
Dunno if I've assumed that much.<br>
<br>
> and that a pointer to a function which takes a type *<br>
> argument can be cast and called as a function which takes a void *.<br>
<br>
Yeah, I've used that.<br>
<br>
> If someone ports CCAN to a platform where those are not true, I'd be<br>
> fascinated...<br>
<br>
--<br>
David Gibson                    | I'll have my music baroque, and my code<br>
david AT <a href="http://gibson.dropbear.id.au" rel="noreferrer" target="_blank">gibson.dropbear.id.au</a>  | minimalist, thank you.  NOT _the_ _other_<br>
                                | _way_ _around_!<br>
<a href="http://www.ozlabs.org/~dgibson" rel="noreferrer" target="_blank">http://www.ozlabs.org/~dgibson</a><br>
</blockquote></div></div>