Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Why _Bool was not defined as enum in C99? Date: Sat, 17 Sep 2016 17:14:53 -0700 Organization: None to speak of Lines: 69 Message-ID: References: <6b5aa241-0498-4e41-993b-a1ed445effb0@googlegroups.com> <405dbd3c-fe4d-41cc-90af-85b319304003@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="15983"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/zWjt5dnlSRYDxiK/dONjt" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:kUdFsMix4B4FE663Cl0jSF8Q68c= sha1:9KeJ9Pi7tri/aZ9Lg1pSndb6ZrU= Xref: csiph.com comp.lang.c:93703 David Brown writes: > On 16/09/16 23:43, Keith Thompson wrote: >> David Brown writes: >> [...] >>> nullptr and nullptr_t have a very specific reason for their existence. >>> NULL is basically just a symbol meaning 0, that people can use if they >>> think it makes their code clearer. But nullptr exists to let function >>> overrides and template matching distinguish between the integer constant >>> 0, and a null pointer. >> >> NULL isn't just 0. In C, NULL expands to an implementation-defined >> null pointer constant. It can be either `0`, or `((void*)0)`, >> or any of a number of other things (including `('/'/'/'-'/'/'/')`, >> which is of course deliberately silly). > > That is true - but I think "NULL is basically just a symbol meaning 0" > is a reasonable simplification. I disagree. NULL is a symbol meaning a null pointer constant. If your simplification were reasonable, it would be reasonable to write: int n = NULL; (And the fact that C uses 0 to represent a null pointer is IMHO a rather odd quirk.) > You can't necessarily use NULL in all > situations where you can use 0 ("int x = NULL;" won't work if NULL is > ((void*) 0), for example). But in situations where you would use NULL, > you can always use 0. And unlike with nullptr in C++, there is no > difference in the meaning of your code if you use 0 instead of NULL. There can be a difference. If NULL is defined as ((void*)0), then printf("%p\n", 0); has undefined behavior, but printf("%p\n", NULL); is well defined, with implementation-defined output. This is not a useful distinction, since NULL can also be defined as 0, which makes both versions UB. These: printf("%p\n", (void*)0); printf("%p\n", (void*)NULL); are both correct and portable. >>> (Personally, I prefer "true" and "false" for bools - but I might use 1 >>> and 0 if I were storing a boolean value in an integer type. >> >> Personally, I prefer to store boolean values in booleans and integer >> values in integers. Of course C doesn't always make that easy. > > I don't normally /choose/ to store a boolean value in an integer type - > but interaction with other things (hardware registers, communication > with other devices, other people's code, etc.) can make those choices > for me. Sure. In such cases, I prefer to make the conversion explicit, for example: bool b = (some_int_value != 0); Of course bool b = some_int_value; is perfectly valid; I just find the version with the comparison clearer. YMMV. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"