From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2556 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: NULL Date: Sat, 12 Jan 2013 00:56:08 -0600 Message-ID: <1357973768.32505.5@driftwood> References: <20130109153630.GZ20323@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 1357973786 8784 80.91.229.3 (12 Jan 2013 06:56:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jan 2013 06:56:26 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-2557-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jan 12 07:56:44 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 1Ttv1D-000160-Ai for gllmg-musl@plane.gmane.org; Sat, 12 Jan 2013 07:56:39 +0100 Original-Received: (qmail 25854 invoked by uid 550); 12 Jan 2013 06:56:22 -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 25846 invoked from network); 12 Jan 2013 06:56:22 -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:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=5Bzj/Ef5wQHu3BZ5AfCjtkCIPHGAc3hz34/dMg0/W64=; b=kUuLFDii9wbujWHRrTIs0Z7Q24oU3UGlEoXSLZEUAZ+JlDX2xHcM10iwqCQsLR5sVZ Cq5Da/B4drzezN35cuD89hxsCMw9IlsDzmZwiGlRwk8rthgudkshD/Bo57thk7V/XuwG koUlCAWc69Y3UxXBS+61gc1Gn0vIRIHYo1QU9ssLPFDD7woQm23PND4Bd5a68Xx1rkQY F1zJpJEGnyNwjwj4rz9dda/z04SwdPfcDrw/RRazrMkhNKEJDFewYToJs3PGIvp8cGtU rWXg9sTY9OdEnAyBkIfqLzu1MPBja/woPtsrXkN6yXZtCUQjrKmrSsDfTbKVIm7xaoit j7Ww== X-Received: by 10.60.6.194 with SMTP id d2mr45583323oea.49.1357973770827; Fri, 11 Jan 2013 22:56:10 -0800 (PST) In-Reply-To: <20130109153630.GZ20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Wed Jan 9 09:36:30 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQm7D3ZJ/sXMqrrFOuaBN6cbx5YJbr/v4efRa7ajlQaZZGru/7DiOFj9L25Wk/JaknYLFPJT Xref: news.gmane.org gmane.linux.lib.musl.general:2556 Archived-At: On 01/09/2013 09:36:30 AM, Rich Felker wrote: > On Wed, Jan 09, 2013 at 04:18:12PM +0100, John Spencer wrote: > > >__attribute__ ((sentinel)) may be used. Adding this to the =20 > appropriate > > >gtk headers (even just as a temporary debugging measure if it's not > > >desirable permanently) would catch all the bugs calling gtk =20 > variadic > > >functions. > > > > > > > indeed this does emit a warning. however, it will only detect > > sentinels, not other variadic arguments that are expected to be > > pointers but will be passed as int instead. i haven't tested, but it > > will most likely also cause crashes. >=20 > Indeed, you are correct. I suspect most such uses _also_ have a > sentinel where incorrect code will also mess up the sentinel, but in > principle it's possible that this does not happen. >=20 > A good system of static analysis for variadic functions would need > some way to express the interface contract in terms of a predicate on > the argument types (and possibly contents) of arguments. I'm not aware > of any such system existing, so the matter falls back to whether we > would really need it to avoid all these bugs. You mean like "__attribute__ ((__format__ (__printf__, 2, 3)));"? This is the job of lint's descendents (ala the stanford checker or =20 sparse). This is really not the compiler's job. (The printf checking is =20 bad enough and it's hardwiring in constraints expressed in the C =20 standard. If you write your own function that's implementing its own =20 rules, the compiler has no idea what you did. Working _out_ what you =20 did equals solving the halting problem.) > > >If we decide something is needed at the musl level, in my opinion =20 > the > > >only acceptable solution is just replacing 0 with 0L =20 > unconditionally. > > >Actually I'd like to remove the special-case for C++ and make NULL > > >_always_ be defined to 0 or 0L, but I worry too many people would > > >complain... > > > > yes, 0L is definitely nicer. > > regarding C code, it would infact be more consequent if you make it > > 0/0L there as well. > > what issues could arise in C code when (void* ) 0 is replaced with =20 > 0L ? >=20 > The original reason I left NULL with pointer type was to catch the > other idiotic error: >=20 > str[len]=3DNULL; >=20 > i.e. confusion of NULL with ASCII NUL. They're both 0. If the optimizer can't convert the type down when =20 handed a constant assignment, the optimizer should be shot. (That said, I use 0 in my code instead of NUL or '\0' because 0 is 0.) > However, this raises a good > question: short of C11 _Generic, is it even possible for a program to > detect whether NULL has integer or pointer type? The C99 standard says that NULL has pointer type. Thus when you pass it =20 in varargs, it should be a long on any LP64 system which is basically =20 "everything but windows" for about 20 years now. > I know of one way, but it's very obscure: You can do sizeof(NULL) and (char *)(NULL+1)-(char *)(NULL) to get the =20 size of the type it points to? 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. And =20 referring to "i++" and "i" in the same statement is explicitly =20 undefined behavior (comma is not a sequence point, the compiler is free =20 to evaluate those in any order and different optimization flags _will_ =20 change that order; I got bit by that many moons ago). Rob=