Re: NULL and zeros

Yevgen Muntyan wrote:
Richard Heathfield wrote:
Christopher Layne said:
Richard Heathfield wrote:

[defensive programming yadda yadda]

I meant it is *implied* and was not written because it wasn't relevant to the discussion at hand.

I understood what you meant by "implied", and my previous answer to that point remains valid IMHO.

You clipped my last segment.

Oops.

If a machine expressed integer 0 as all 1 bits internally, and I called
memset(&object, 0, sizeof(object)); that's going to result in object set
to all 0 bits?

Yes, it must. The machine's bizarre internal representation does not excuse the implementation from its obligations. The semantics of memset(&object, 0, sizeof(object)) is "starting at the address indicated by object, set sizeof(object) bytes to the value (unsigned char)0". If object has integer type then that process must have the effect of setting object's value to 0. If it has some other type, however, there is no such requirement.

Standard says in 7.20.3.1: "The calloc function allocates space for an array of nmemb objects, each of whose size
is size. The space is initialized to all bits zero."
It looks like "starting at the address indicated by object, set
> sizeof(object) bytes to the value (unsigned char)0" is your own
interpretation caused by the knowledge of real world computers and
compilers :)

No, unsigned char is _guaranteed_ to have no padding bits. In addition,
it is an unsigned integer type, so the representation of
(unsigned char)0 indeed is "one byte with all bits 0".
So, Richard described it equivalently using his knowledge of the
standard.
No undue "real world" knowledge required to arrive at that one.


Anyway, this newsgroup is not comp.std.c is it?

You clearly did not bother to do your "homework", i.e. finding out
what this newsgroup considers topical. I suggest reading
http://clc-wiki.net/wiki/intro_to_clc
and especially
http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction#topical

So you are playing
games with standard here; you are saying "On some machines, that isn't
the case. If you are excluding such machines, you are in the wrong newsgroup.", and it's no good. Show me chunk of real world code
which will work on any machine covered by standard; or stop pretending
C doesn't mean a programming language used in real world.

Once again: Richard's position is correct for comp.lang.c -- apart
from that, and back to your original question:
- whenever I find some calloc() in someone's code, I assume that
the originator of this calloc() is clueless -- my personal
experience points to this relationship.
- I prefer the "constructor" or "init element" methods for setting
up struct types that may vary during development.
- The compiler may well optimise a malloc() call followed by a
check for NULL followed by an initialisation to effectively all
bits zero by a call to calloc() if deemed necessary.
- In addition, I often have entries that need not be initialised
to zero -- why have the overhead of calloc() to set the respective
bytes to all bits zero?

Apart from that: It is possible to write real world programmes that
run on "virtually all" hosted implementations -- implementation limits
may make the programme fail consistently, though.
In addition, one usually strives to keep the portable part of other
programmes as large as possible and isolate non-portable parts in
a couple of headers and/or modules.


The question was specifically about existence of machines with certain
properties, for a real world application, not about whether standard
says yes or no about some particular thing.

There are _many_ past threads enumerating machines with null pointers
being not all bits zero. Whether you consider these machines relevant
is your decision. However, your position reads to me "I am making
non-portable assumptions but I think these are not too restrictive
and quite portable for what I want to do -- please confirm this".
Without giving us _all_ the data for a well-founded expert placet to
this. The only possible answer can be "it is not portable, so this
practice is ill-advised".


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
.

Relevant Pages

  • Re: NULL and zeros
    ... Standard says in 7.20.3.1: "The calloc function allocates space for an array of nmemb objects, ... If you are excluding such machines, you are in the wrong newsgroup.", and it's no good. ... bits zero by a call to callocif deemed necessary. ...
    (comp.lang.c)
  • Re: NULL and zeros
    ... The machine's bizarre internal representation does not excuse the implementation from its obligations. ... standard. ... The standard indeed does not specify what an "all bytes zero" or "all ... the originator of this calloc() is clueless -- my personal ...
    (comp.lang.c)
  • Re: NULL and zeros
    ... behavior very well justifies using of calloc(), ... worked with platforms where all bits zero did not give you floating ... or that you need to check malloc() return value. ... I have initmethods, but they do not allocate memory, that's done ...
    (comp.lang.c)
  • Re: Null pointers
    ... >> zero in memory. ... machines that have RAM at location 0.) ... - The NULL macro, and the null pointer constants, are source ...
    (comp.lang.c)
  • Re: Definition of NULL
    ... array to all bits zero has been addressed thoroughly in other posts, ... mentioned another reason why the initialization loop is not equivalent in your ... example to the calloc approach. ... You don't loop over all the elements in the array, as you made an off by one ...
    (comp.lang.c)