Re: Proper way to check malloc return

gordonb.f6x43@xxxxxxxxxxx (Gordon Burditt) writes:
andy_P <andypanov@xxxxxxxxx> wrote (and Gordon Burditt refused to
acknowledge):
I am still convinced that pointer comparison should be used in C
instead of if(ptr) form.

If that statement is for stylistic reasons, you are entitled to your
opinion.

If that statement is for alleged portability reasons, you are wrong.
Any compiler that gets that wrong is so broken you will have a lot of
problems compiling existing code.

I'd say that any compiler that gets that wrong is not a C compiler,
and you're not likely to find it unless you're in the early stages
of implementing it yourself.

The C standard does not require a null pointer to be represented
as the bit pattern 0xdeadbeef, even on 32-bit machines, nor does
it require a null pointer to be represented as 0xdeadbeefdeadbeef
on 64-bit machines. However, if it does have that 32-bit representation,
all 3 sets of code:

if (ptr) { ... }
and
if (ptr != 0) { ... }
and
if (ptr != NULL) { ... }

may all generate the same code, which might be:
[snip]
In any case, a good compiler will generate identical code for all three
code fragments. The behavior of the C code does *NOT* depend on whether
the internal representation of a null pointer is or isn't all-bits-zero.

Ah, but his argument wasn't based on the representation of a null
pointer, it was based on the assumption that "if (ptr)" performs
an implicit conversion of ptr to some integral type. If that
assumption were correct, he'd be correct, since the result of such
a conversion is implementation-defined. But the assumption was
incorrect, as I explained a while ago; "if (ptr)" compares ptr to
0, which results in 0 being converted to the pointer type, which
is a well defined operation.

[As always, permission to quote my Usenet postings is granted if
and only if they are properly attributed.]

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: CPtrList - Please Help me understand
    ... object of type notice*, and you won't need to do casts at all. ... >Now although bp has a pointer to an object of type B (which we know because we created ... >compiler now happily does the assignment. ... >Generally, casting has no effect on the representation of a value, other than instructing ...
    (microsoft.public.vc.mfc)
  • Re: Why MFC doesnt like /vmg?
    ... These options select the method that the compiler uses to represent pointers ... to specify a pointer representation. ... before you declare a pointer to a member of the class. ... pointer to a member of a class before defining the class. ...
    (microsoft.public.vc.mfc)
  • Re: Pointer equality and dereferencing
    ... representation using some non-trivial algorithm. ... compiler might mistake it for a pointer that points to one past some array ... definition outside the scope of the standard, ...
    (comp.std.c)
  • Re: Function pointer question P119 K&R
    ... representation and alignment requirements as a pointer to a character ... the compiler knowing what the function expects. ... then any void* whose value is properly aligned for the object ...
    (comp.lang.c)
  • Re: C- Syntax to allocate Global variables to consecutive memory locations
    ... I still wasn't clear enough - the above code is generated by a C compiler. ... pointer than it is to optimise away the const pointer completely you need ... to look for ptr in the data segment not at the generated code using ptr. ...
    (comp.arch.embedded)