Re: NULL and zeros

Eric Sosman wrote:

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.

I am not writing code which depends only on C library. In this case
it depends on GTK library, and "portability" means "works on any
GTK-supported platform". If it's cheap to write portable code, it's
better to write portable code; if it's cheaper to assume bytes
are 8 bits, it's better to assume that. Exactly what you said, except
that "portability" is "real portability", not "portable to any
possible computer with C compiler".

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?"

Did I ask that (not sure what)?

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().

No, I modify it all the time ("active development" phase), and I do
forget to put NULL initializers for new structure members, and I hate
removing useless obj->something = NULL; lines, and I don't like seeing
those either. Now, it's really a problem of not having nice design.
"Sloppy design, sloppy code" you might say. Or, "RAD", others may say ;)

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.

Yes, those init() functions are very easy to find, no problem
with that. But having useless lines of code is a problem. It is useless,
you know it's useless, so naturally you stop caring about it (not
intentionally, no, you are good person, it's just laziness and such)
and you need to remember about portability and force yourself to do the
"right" thing. It's much easier not to make "bad" things when you know
they actually hurt someone, you know.

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

Apples. Are there blue oranges with melon taste yet? And do I care
about those hypothetical artificial fruits?

Best regards,
Yevgen
.

Relevant Pages

  • Re: C language portability support
    ... > What the hell has this got to do with portability? ... any platform that didn't support it was so weird that it wouldn't be worth ... and a struct COLOUR so ... Who the hell ...
    (comp.lang.c)
  • Static member initialization
    ... is it possible to initialize such a static member that need some algorithm ... Example: Platform VC++7.1 ... using namespace std; ... struct A { ...
    (comp.lang.cpp)
  • Static member initialization
    ... is it possible to initialize such a static member that need some algorithm ... Example: Platform VC++7.1 ... using namespace std; ... struct A { ...
    (microsoft.public.vc.language)
  • Re: C portability is a myth
    ... Of course it was the C standard itself which was ... I did not even think about portability. ... platform, all compliant with the exact same version of the ANSI C ... its a limiting factor on availability. ...
    (comp.lang.c)
  • Re: <ctype.h> toLower()
    ... See the C Standard. ... >> tolower() is implemented. ... >> platform, without even having to know which character set is used on that ... is, however, an error in portability for me to *call* that macro. ...
    (alt.comp.lang.learn.c-cpp)