Re: NULL and zeros

Yevgen Muntyan wrote:
Eric Sosman wrote:

Yevgen Muntyan wrote:

Hey,

Are there not highly specialized and still existing and used platforms
where NULL is not a sequence of zeros, so that "char *a = NULL;" and
"char *a; memset (&a, 0, sizeof (a));" are not equivalent?

In other words, do I care about possible difference between NULL and
zero-filled pointer if e.g. I assume the target platform can run X
or it is Windows?

Have you read Question 5.17 in the comp.lang.c Frequently
Asked Questions (FAQ) list at <http://c-faq.com/>?

Also, have you read the tenth of the Ten Commandments for
C Programmers at <http://www.plethora.net/~seebs/c/10com.html>?


I have read those, and it's why I'm asking. Question is: is true
*hypothetical* portability more important than convenience in my
specific case?

It comes down to how highly you value convenience and how
highly you value portability. That is, it comes down to two
matters of your own tastes and desires, not to the experiences
of other people. So why ask at all? It's like asking "Should
I prefer apples or oranges?"

It's lot of lines of obj->this = NULL; obj->that = NULL;
I get zero-initialized structures for free and would really love
not to have to initialize all pointers inside. Besides, lot of
NULL initializations makes code actually harder to modify - you need
to consult header to know whether you got all should-be-NULL actually
NULL's.

If you want to initialize a struct without knowing what elements
the struct contains, you're on shaky ground already. It seems you
may be worried about

void init_struct(struct s *ptr) {
ptr->p1 = NULL;
ptr->p2 = NULL;
}

.... where somebody might come along at a later date and add a p3
element, which would then go uninitialized unless he also remembered
to modify init_struct(). If that's the issue, I've got two answers:
First, somebody who modifies a data structure should also take the
responsibility of keeping its "constructors" and "renderers" and so
on up-to-date, and the code should be arranged in such a way that
the data type's "fundamental operators" are easy to find -- in fact,
hard for him to avoid. That's really a social problem, not a
programming problem, and you need to employ social pressures like
coding standards to keep the problem under control.

Second, a technical solution for the special case where you'd
like to initialize to "all members zero" (which may or may not be
"all bits zero") without worrying about the elements individually:

void init_struct(struct s *ptr) {
static const struct s all_zeroes;
*ptr = all_zeroes;
}

Which do you like more? Or do you prefer calloc()? Apples,
oranges, or pears?

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • [2.6 patch] SCTP: possible cleanups
    ... typedef struct sctp_cmsgs { ... /* Initialize a block of memory as a command sequence. ... /* Get the size of a DATA chunk payload. ... +static void sctp_datamsg_init ...
    (Linux-Kernel)
  • Re: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
    ... it does not "correctly" initialize the waitqueue. ... *parent, struct inode *dir, struct n ... +static inline void ...
    (Linux-Kernel)
  • Re: [PATCH 2/3] user.c: use kmem_cache_zalloc()
    ... struct user_struct *new; ... atomic_t contains just a solitary int member, ... that the *zalloc() is assumed to initialize to zero. ...
    (Linux-Kernel)
  • Re: Some issue with pointers
    ... typedef struct menu { ... void *vp; ... Now I want to initialize the second element ... {0, myfunc} ...
    (comp.lang.c)
  • Re: nested structures and initialization
    ... typedef struct trans Transient; ... float radar; ... you might have quite a lot of different structures to initialize. ... You need to allocate memory for each one, just as I described above for the pointer members of sptr itself. ...
    (comp.lang.c)