mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: NULL
Date: Sun, 13 Jan 2013 18:47:32 +0100	[thread overview]
Message-ID: <20130113174731.GS4468@port70.net> (raw)
In-Reply-To: <1358087360.32505.12@driftwood>

* Rob Landley <rob@landley.net> [2013-01-13 08:29:20 -0600]:
> On 01/12/2013 07:31:14 AM, Rich Felker wrote:
> >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.
> 
> Really?
> 
> Toybox main.c is doing:
> 
>   #define NEWTOY(name, opts, flags) opts ||
>   #define OLDTOY(name, oldname, opts, flags) opts ||
>   static const int NEED_OPTIONS =
>   #include "generated/newtoys.h"
>   0;  // Ends the opts || opts || opts...
> 
> Which basically boils down to either:
> 
>   NEED_OPTIONS = "STRING" || NULL || "STRING";
> 
> Or:
> 
>   NEED_OPTIONS = 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
> only ever called behind and if (0). I tested this to make sure it
> worked. Years ago I actually upgraded tinycc to make that behave the
> same way gcc behaved so it could build this. (Yes, I could make it a
> compile probe setting a config symbol before the main build, but I
> didn't _need_ to.)
> 
> So I think you're saying is that the behavior I'm depending on changed?

well,

(int)(void*)0 is not an "integer constant expression" and it
is not a "null pointer constant", it is not an "arithmetic
constant expression" nor an "address constant", but an
implementation is allowed to accept it as a "constant expression"
anyway
(as far as i can see it is not required to though)

!(void*)0 and (void*)0 || (void*)0 are similar

in initializers they may be accepted, but the standard
does not require them to be

gcc used to be less strict integer constant expressions,
but recently it follows the standard more closely

> Sigh. Yup. When I build toybox with just "true", gcc 4.2.1 (last gpl
> release) drops out parse_optflag() but the ubuntu host toolchain no
> longer does.

i think gcc should be able to do the optimization

i guess gcc assumes that the value of 'static const' objects
may change or may not be available at compile-time for some
reason

may be the following works:

  #define NEWTOY(name, opts, flags) opts ||
  #define OLDTOY(name, oldname, opts, flags) opts ||
  if (
  #include "generated/newtoys.h"
  0) call_option_parsing_stuff();


  parent reply	other threads:[~2013-01-13 17:47 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09 11:02 NULL John Spencer
2013-01-09 12:18 ` NULL Szabolcs Nagy
2013-01-09 13:36   ` NULL John Spencer
2013-01-12  6:32     ` NULL Rob Landley
2013-01-12  6:46       ` NULL Rich Felker
2013-01-12  7:15         ` NULL Luca Barbato
2013-01-12 13:33           ` NULL Rich Felker
2013-01-12 11:39       ` NULL Jens Staal
2013-01-09 13:09 ` NULL croco
2013-01-09 13:47   ` NULL John Spencer
2013-01-09 14:49     ` NULL croco
2013-01-09 14:42 ` NULL Luca Barbato
2013-01-09 14:47   ` NULL Rich Felker
2013-01-09 15:03     ` NULL Luca Barbato
2013-01-09 15:18     ` NULL John Spencer
2013-01-09 15:36       ` NULL Rich Felker
2013-01-09 21:11         ` NULL Rob
2013-01-09 21:53           ` NULL Szabolcs Nagy
2013-01-09 22:17             ` NULL Rob
2013-01-09 23:42         ` NULL Szabolcs Nagy
2013-01-12  6:56         ` NULL Rob Landley
2013-01-12  7:07           ` NULL Bobby Bingham
2013-01-12 13:31           ` NULL Rich Felker
2013-01-13 14:29             ` NULL Rob Landley
2013-01-13 14:56               ` NULL Luca Barbato
2013-01-13 16:29                 ` NULL Rob Landley
2013-01-13 17:14                   ` NULL Luca Barbato
2013-01-13 15:23               ` NULL Strake
2013-01-13 17:17                 ` NULL Luca Barbato
2013-01-13 17:47               ` Szabolcs Nagy [this message]
2013-01-13 19:46                 ` NULL Rob Landley
2013-01-14  6:11                   ` NULL Rich Felker
2013-01-14  8:45                     ` musl as a framework to test applications' compatibility with POSIX (was: NULL) Vasily Kulikov
2013-01-14 14:03                       ` Rich Felker
2013-01-14 14:30                         ` Vasily Kulikov
2013-01-14 15:02                           ` Szabolcs Nagy
2013-01-14 15:14                           ` Rich Felker
2013-01-14 13:19                     ` NULL Rob Landley
2013-01-12  5:56 ` NULL Rob Landley
2013-01-12  6:42   ` NULL Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130113174731.GS4468@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).