Hacker News Reader

"warning: initialization makes integer from pointer without a cast"

I mean sure, there are warnings and there are warnings. Absurdist pedantry about warning states isn't something I tend to worry about.

But if you're dealing with a code base that is building to completion without attention to this warning (which pops out with the default flags on gcc 4.7.2 -- no -Wall needed!), then you have more serious problems than can be fixed by a builtin pointer-to-bool conversion.

Arguably that warning just suggests that you put in a cast, which makes it no more correct. Then you get another warning "cast from pointer to integer of different size [-Wpointer-to-int-cast]" which apparently is also on by default, but I'm not sure it's immediately obvious to a casual C programmer how that will go wrong.

Again, I'd argue that if you have a programmer willing to throw in a double cast expression (!) to work around a warning without once thinking about what they are trying to do (in this case to check if a pointer is NULL) then you have problems that aren't going to be well addressed by a C99 bool anyway.

I mean, this example is a little contrived as it is. The "normal" way to treat a pointer as a boolean and branch off of it is just "if(ptr)", and that's worked without trouble on all compilers for 40 years now.

Is C sort of a mess? Yeah. But this isn't a particularly illustrative example IMHO. All languages have this nonsense (c.f. the Ruby/JS "Wat" video).

No it doesn't. Not to anyone who knows C anyway.

Casting pointers to integers isn't all that common to do. When I see that warning, I take it very seriously, because it almost always means I made a real mistake.

It's gotten better the last few years, but I still see that exact warning all the time in open-source projects. Nobody cares about warnings until someone mandates -Werror.

CFLAGS+=-Wall -Wextra -pedantic -Werror # have fun

This pointer-to-bool bug isn't theoretical, either—it happened to me just a few months ago. The Cocoa function NSAssert works on objects, and raises an exception on a nil pointer. A similar assertion in a library I was using was simply casting to BOOL (a signed char), causing the error you described. It was a nightmare to debug, since it was interacting with a black box that I believed was the source of the problem.

Another problem with that typedef and usage is that it assumes that NULL as an integer is 0. It need not be. The literal constant 0 cast to or assigned to a pointer type always works because they compiler treats that as a special case, and replaces the 0 with whatever the actual NULL bit pattern for that pointer type. E.g., "char * p = 0" might actually generate something like "move #0xFFFFFFFF, p" on a machine where 0xFFFFFFFF is the bit pattern for NULL char pointers.

A lot of people forget this, and think that NULL pointers must actually have a bit pattern that is all zeros.

Name me a common system where NULL != 0

You might as well be worrying about code compatibility with systems that have a 7 bit char, or some other irrelevance.

C++ member pointers are frequently represented as offsets into the class on vanilla x86. Given that 0 is an entirely valid offset -- the first member given a class without initial padding or vtable -- NULL must of course be represented by an entirely different, nonzero, bitpattern.

hmm? you're adding an offset to a pointer (the base of the object), which is still not going to equal 0 even if the offset is 0.

The C++ standard calls pointers to members... well, pointers to members. I'm not offsetting anything: The compiler is on my behalf. It could create function stubs for all I care, similar to how one might emulate this feature in C#.

  #include <iostream>

  struct Foo
  {
  	int bar;
  };

  int main()
  {
  	int (Foo::*null_pointer) = nullptr;
  	int (Foo::*first_member_pointer) = &Foo::bar;
  
  	std::cout << *(std::ptrdiff_t*)&null_pointer << "\n";
  	std::cout << *(std::ptrdiff_t*)&first_member_pointer << "\n";
  }

Running this code after compiling it with VS2012 results in, on my machine:

  -1
  0

That's simply not true. There is the rule, that NULL must be equal to (void *)0. I had also several discussions about that topic, but it's part of at least C99 and C11.

Yes, (void * )0 gives a null pointer. I mentioned that. However, that doesn't mean all the bits of a null pointer are required to be all 0. The actual machine representation of a null pointer is implementation-defined. The only requirement C99 places on the actual value of a null pointer is that it compares unequal to a pointer to any object or function, and any two null pointers compare equal. See section 6.3.2.3 paragraphs 3 and 4:

   An integer constant expression with the value 0, or
   such an expression cast to type void *, is called a
   null pointer constant. If a null pointer constant
   is converted to a pointer type, the resulting pointer,
   called a null pointer, is guaranteed to compare unequal
   to a pointer to any object or function.

   Conversion of a null pointer to another pointer type
   yields a null pointer of that type. Any two null pointers
   shall compare equal.

If you do this:

   int pv = 0;
   char * p = (char *)pv;

you are not guaranteed to have p set to a null pointer, because the zero you are casting and assigning is not an integer constant zero. The behavior is implementation-defined, as is going the other way. Section 6.3.2.3 paragraphs 5 and 6:

   An integer may be converted to any pointer type. Except
   as previously specified, the result is implementation-defined,
   might not be correctly aligned, might not point to an entity
   of the referenced type, and might be a trap representation.

   Any pointer type may be converted to an integer type. Except
   as previously specified, the result is implementation-defined.
   If the result cannot be represented in the integer type, the
   behavior is undefined. The result need not be in the range of
   values of any integer type.

This should be okay, though:

   char *p1 = 0;
   int pv = (intptr_t)p1;
   char *p2 = (char *)pv;

I.e. NULL must round-trip through intptr_t.

As a really bad C programmer I have a question, if you don't mind my asking:

Is that the kind of knowledge/insight you gain from understanding C when studying it or when you are bitten by a bug ?

You get that kind of insight by reading the specification. If you are anything like me, you'll only actually read it when you are bitten by a bug.

But that's not universal, there are people that like to know the ins and outs of the language before using it... and yes, they are the ones doing the right thing.

>> As a C99 feature, bool is too little, too late; had it been part of C89, things might be different.

I'm failing to understand this line. Can you be more explicit why it's bad now, and would have been good earlier?

Because lots of compilers in common use, particularly from Microsoft, don't support C99 so to work around their assheadedness you have to put in compatibility workarounds. Those workarounds behave differently from compiler-implemented bool, and the risk of errors from those inconsistencies is significantly greater than the benefit of using bool in code.

"Lots of" compilers in common use? Can you name one besides Microsoft's?

Linus is usually dead-on in language matters.

bool as a type in C strikes me as dubious. In C, you need to care about the underlying representation of things. I'm not even sure it was a good idea to call a char a char, because it's actually a small integer. Calling it a char is just misleading; it's signed, and a literal character is not even a char. It's a source of bugs. "bool" sounds potentially worse.

That needed to be clarified and was missing in Linus reply. It is a very important point, from the language perspective.

Probably better:

    bool found_it = !!strstr(haystack, needle);

In the example you gave, any compiler from the last 10 years would have given a warning message when converting the pointer to an int. Ignoring error messages is extremely, extremely bad practice. If you are still doing that, I suggest auditing your code right now to see if there are more problems such as mismatched printf arguments and so forth.

bool is a bad thing in C and C++, because of the implicit conversion rules. In C++, pointers implicitly convert to bool in every context-- there is never any warning message. This effectively reduces the compiler's ability to typecheck your program, since so many variables are pointers already, and C++ will happily stuff them into any bool argument to a function.

It seems like the C99 _Bool type implements the same implicit type conversion brain damage. That makes it a step backwards in terms of type safety, not forwards. That's right, using the old-fashioned, fuddy-duddy, plain old int and 0 and 1 gives you better type checking than the shiny new C++ feature.

As Linux points out, the worse typechecking comes with a side order of compatibility problems. And it is not any more efficient or readable.

It seems like the C99 _Bool type implements the same implicit type conversion brain damage.

It does: "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." (from §6.3.1.2 of the N1256 draft)

Compilers will happily compare/set pointers to 0 since that's the null pointer constant (§6.5.9, §6.3.2.3), so there's no warning:

    % cat foo.c
    #include <stdio.h>
    int main() { _Bool b = "blah"; printf("%d\n", b); return 0; }
    
    % gcc -std=c99 -W -Wall -Wextra -o foo foo.c
    
    % ./foo
    1

Have you ever actually encountered a bug involving accidentally passing a pointer to a 'bool' function argument? I've seen many obscure kinds of bugs, but don't remember ever in my life seeing one of those- so I suspect this is a red herring.

(And of course if the value passed happens to be an int rather than a pointer, typedefing bool to int won't save you!)

edit: And as mentioned in the rest of the thread, while it's unjustifiably confusing to, say, pass 'p' as a boolean parameter rather than 'p != NULL', it's not unreasonable to do something like

    typedef int bool;
    bool foo_enabled;
    void set_foo_enabled(bool enabled) {
        if(enabled == foo_enabled) return;
        /* new value is different, do some work */
    }
    set_foo_enabled(1);
    ...
    set_foo_enabled(flags & ENABLE_FOO);

Though I haven't come across this kind of bug in practice either.

I've encountered a bug like that when the callee was converted from taking a pointer to taking a bool and the caller was not updated because it compiled fine...