Re: [dwm] malloc'ed client in manage()

Szabolcs Nagy wrote:
> On 9/7/08, Matthias-Christian Ott <ott_AT_enolink.de> wrote:
> > Nicolas Martyanoff wrote:
> >
> > Does anyone know whether there are architectures where NULL is not equal
> > to 0?
>
> this question occasionally appears on comp.lang.c and there exists
> such beast, but i cannot find the reference now
>
> probably it's some old or otherwise esoteric architecture
>
> > See ISO/IEC 9899:TC2 Section 7.17.3:
> >
> > "The macros are NULL which expands to an implementation-defined null
> > pointer constant and; ..."
> >
> > See ISO/IEC 9899:TC2 Section 6.3.2.3.3:
> > "An integer constant expression with the value 0, or such an
> > expression cast to type void *, is called a null pointer constant."
> >
> > Seems like a contradiction in the C99 standard (I have to admit that my
> > version is a Committee Draft).
>
> there is no contradiction

OK, if think about the phrase "implementation-defined null pointer
constant" twice, it becomes clear that this means that NULL can be
defined in one of the following ways:

#define NULL (void *)0

or

#define NULL 0

I overread "null pointer constant" and thought that they first mention
that NULL is implementation-defined and then state that NULL is 0 oder
(void *)0.
 
> '0' can simply mean 2 completely different things: null pointer in
> pointer context, or integer 0 otherwise
>
> so a _constant_ integer expression with value 0 automagically becomes
> a null pointer which may or may not be represented internally by all
> bits zero
>
> (but eg an integer 0 must be represented by all bits zero)
>
> > See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 4.10:
> > "A null pointer constant is an integer constant expression (5.19)
> > rvalue of integer type that evaluates to zero."
> >
> > See ISO/IEC 14882:1998 and ISO/IEC 14882:2003 Section 18 Footnote 180:
> > "Possible definitions include 0 and 0L, but not (void *)0."
> >
> > And this sounds like a conflict between C and C++.
>
> yes, c++ was developped with this design decision from the start
>
> > But anyhow it seems that you can't do this reliably, because s isn't
> > used by memset as a pointer.
> >
> > memset(&s, 0, sizeof(s));
> >
> > where s is a struct.
>
> yes, that's the point: according to standard calloc is not ok, but
> default struct initialization is
>
> (but we can overlook this since X won't run such weird architecture)
 
I mean this whole NULL pointer thing scarses me. First they thought: OK,
NULL was always synonimous with 0, so let's say if someone assigns 0 to
a pointer lets make it a "hardware NULL" (which isn't 0 on some
architectures). But what follows is that all code that generalises the
"pointer = 0" principle to "variable = 0, cast to pointer" to be the
same becomes invalid. That's so stupid.
In my code I'll assume that memset(&s, 0, sizeof(s)); works for all
pointers.

> > According to ISO/IEC 9899:TC2 Section 6.7.8.1 and Section 6.7.8.10 this
> > would be correct:
> >
> > s = {0}; or s = 0;
> >
> > Anyhow it's not working with gcc.
>
> in c99 you initialize a struct to zero with:
>
> struct_t s = {};

But anyways I'm not sure whether static char *p is equal to char *p =
NULL.

Regards
Matthias-Christian
Received on Sun Sep 07 2008 - 18:46:01 UTC