From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2564 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: NULL Date: Sun, 13 Jan 2013 08:29:20 -0600 Message-ID: <1358087360.32505.12@driftwood> References: <20130112133114.GH20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1358087376 5992 80.91.229.3 (13 Jan 2013 14:29:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Jan 2013 14:29:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2565-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 13 15:29:54 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TuOZM-00036V-Nh for gllmg-musl@plane.gmane.org; Sun, 13 Jan 2013 15:29:52 +0100 Original-Received: (qmail 16325 invoked by uid 550); 13 Jan 2013 14:29:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16317 invoked from network); 13 Jan 2013 14:29:34 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:subject:to:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=AsF9Tm0MErzbtSxwA/JWI3gCWdXiZGKVPk2UBm6PeBk=; b=ld6RSERJSLKyaFqy32Zmr7W43s7oxc6UiY366/P5zKhZMUuJlJnDDa1NBSE2lJAvBV 7rWEC5geRi79OgjFQ3Klm+5/dTp/4kbmcf8DQGObb9ofRzrezNxgCu+H3B6ZTZvnBCHb s07/x1PYu/5/j4tusWxDJ4aohKOeeZ9B4RiKXoNtOQvHEs4cdw7RzaNI51HrB7RR5K0x tnXmJ3SeXTlRb9cx8iwxyxOib5YjIhgarC/1+QD7gDqvePIOrarHH10OrVWe+7jBD3M0 3mgpdXN7kLbkLBA4cYBZVfCy4a6ygIwAGr6zlQ5LBvWhcOtFioPCAyjW21QYJDCY3EVp 920Q== X-Received: by 10.60.32.147 with SMTP id j19mr50069271oei.68.1358087362835; Sun, 13 Jan 2013 06:29:22 -0800 (PST) In-Reply-To: <20130112133114.GH20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Sat Jan 12 07:31:14 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQkSFwuKg/rZNyI7wW0UYnd8OGFzy+1OEeat4Yo5nt9VyRRTgUbASAM0hAa5E049YOKSRRzG Xref: news.gmane.org gmane.linux.lib.musl.general:2564 Archived-At: On 01/12/2013 07:31:14 AM, Rich Felker wrote: > On Sat, Jan 12, 2013 at 12:56:08AM -0600, Rob Landley wrote: > > >The original reason I left NULL with pointer type was to catch the > > >other idiotic error: > > > > > > str[len]=3DNULL; > > > > > >i.e. confusion of NULL with ASCII NUL. > > > > They're both 0. If the optimizer can't convert the type down when > > handed a constant assignment, the optimizer should be shot. >=20 > No. ASCII nul is an integer 0. NULL is a null pointer constant, which > may be an integer constant expression 0 or may be (void *)0. Ah right, possible warning. (Behavior's guaranteed correct in this =20 instance, but the compiler complains anyway.) > > >However, this raises a good > > >question: short of C11 _Generic, is it even possible for a program =20 > to > > >detect whether NULL has integer or pointer type? > > > > The C99 standard says that NULL has pointer type. Thus when you pass >=20 > No it does not. We have addressed this multiple times already. You read the standard as saying a pointer constant does not need =20 pointer type. *shrug* Ok... > > it in varargs, it should be a long on any LP64 system which is > > basically "everything but windows" for about 20 years now. >=20 > Actually the type doesn't matter to correct programs. The question is > whether we want to coddle incorrect programs, and the answer folks > seem to be leaning towards is yes, in which case 0L would be the right > definition to accomplish this. I read "incorrect programs" and "c++ programs" as synonymous, but I'm =20 biased. > > >I know of one way, but it's very obscure: > > > > You can do sizeof(NULL) and (char *)(NULL+1)-(char *)(NULL) to get > > the size of the type it points to? >=20 > NULL+1 is a constraint violation if NULL has pointer type (since the > only pointer type it's permitted to have is void *). Compile time probe to set a constant with 0 for void? (I've lost track =20 of the entrance to the rathole: why do we need this info?) So it's not required to be a pointer, but it's required to be a void =20 pointer. Weird. (I'm something like 3 years stale on any sort of deep =20 reading of the standards.) > > Not sure what question you're asking... > > > > >int null_is_ptr_type() > > >{ > > > char s[1][1+(int)NULL]; > > > int i =3D 0; > > > return sizeof s[i++], i; > > >} > > > > (int)NULL is 0 according to C99 so the NULL in there has no effect. >=20 > It does. (int)0 is an integer constant expression. (int)(void *)0 > happens to be semantically constant, but it's not an integer constant > expression. Therefore, depending on the definition of NULL, s may be a > regular array type or a variable-length array type. In the latter > case, s[i++] has VLA type and thus sizeof is required to evaluate its > argument. GCC versions prior to 4.5 were buggy in this regard. Really? Toybox main.c is doing: #define NEWTOY(name, opts, flags) opts || #define OLDTOY(name, oldname, opts, flags) opts || static const int NEED_OPTIONS =3D #include "generated/newtoys.h" 0; // Ends the opts || opts || opts... Which basically boils down to either: NEED_OPTIONS =3D "STRING" || NULL || "STRING"; Or: NEED_OPTIONS =3D NULL || NULL || NULL; Then it does: if (NEED_OPTIONS) call_option_parsing_stuff(); And then dead code elimination zaps the option parsing stuff if it's =20 only ever called behind and if (0). I tested this to make sure it =20 worked. Years ago I actually upgraded tinycc to make that behave the =20 same way gcc behaved so it could build this. (Yes, I could make it a =20 compile probe setting a config symbol before the main build, but I =20 didn't _need_ to.) So I think you're saying is that the behavior I'm depending on changed? Sigh. Yup. When I build toybox with just "true", gcc 4.2.1 (last gpl =20 release) drops out parse_optflag() but the ubuntu host toolchain no =20 longer does. So A) your test is unreliable, B) the optimization I'm depending on is =20 unreliable. And it's unreliable _even_ if I replace "NULL" with 0 so it =20 _is_ clearly saying if (0) as a constant? What the...? Hang on, I'm initializing this as a global so that it will FAIL if it's =20 not a constant. (And it still doesn't fail. What's failed is dead code =20 elimination in current gcc is no longer removing functions that can =20 never be accessed, so I have to go figure out what the right compiler =20 flags are called this week. SIGH.) So fond of gcc. The LFS guys are currently discussing the 4.7.2 release =20 or whatever it is that just came out and requires a C++ compiler on the =20 host. (I'd link to the archives but their website is half-migrated =20 right now.) > > And referring to "i++" and "i" in the same statement is explicitly > > undefined behavior (comma is not a sequence point, the compiler is >=20 > Comma is a sequence point. >=20 > > free to evaluate those in any order and different optimization flags > > _will_ change that order; I got bit by that many moons ago). >=20 > No, you were doing something else wrong. To my knowledge there has > never been a compiler that did not honor the comma operator sequence > point, certainly not any GCC or clang. I went and looked it up again: the comma operator and the commas in =20 function arguments are not the same thing. (They _used_ to be, but bad =20 optimizers broke it often enough the standards body caved.) Commas in =20 function calls are not sequence points (c99 3.19), commas outside of =20 function calls are. Wheee... > Rich Rob=