By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,408 Members | 1,914 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,408 IT Pros & Developers. It's quick & easy.

Equivalent malloc with calloc

P: n/a
Do you prefer malloc or calloc?

p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);
p = calloc(size, 1);

Apr 1 '07 #1
Share this Question
Share on Google+
46 Replies


P: n/a
On Apr 1, 4:02 pm, "lovecreatesbea...@gmail.com"
<lovecreatesbea...@gmail.comwrote:
Do you prefer malloc or calloc?
That depends on whether the memory should be initialised to all bits
zero. Sometimes it should, sometimes it shouldn't.
p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);
Here, you're requesting enough space to store an array with 1 element
of size [size].
p = calloc(size, 1);
Here, you're requesting enough space to store an array with [size]
elements of size 1.

In the end, both calls request exactly the same size. The difference
in meaning matters only to anyone reading the code, not to the
compiler or to the computer.

Apr 1 '07 #2

P: n/a
lovecreatesbea...@gmail.com wrote:
Do you prefer malloc or calloc?
Usually malloc, but I also use calloc occasionally, when it's
advantageous to do so.
p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);
p = calloc(size, 1);
Both allocate the same _amount_ of storage as the malloc call, but the
manner in which you'd, presumably, access the storage, and the manner
in which the compiler would translate your source would definitely
differ. Of course, you can always access the storage as a sequence of
bytes, but that would, IMHO, defeat the purpose of using calloc in the
first place.

Apr 1 '07 #3

P: n/a
lovecreatesbea...@gmail.com said:
Do you prefer malloc or calloc?
It depends.
p = malloc(size);

Which of the following two is right to get same storage same as the
above call?

p = calloc(1, size);
p = calloc(size, 1);
Either.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Apr 1 '07 #4

P: n/a
"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
Do you prefer malloc or calloc?
It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 1 '07 #5

P: n/a
On Apr 1, 9:09 pm, Keith Thompson <k...@mib.orgwrote:
"lovecreatesbea...@gmail.com" <lovecreatesbea...@gmail.comwrites:
Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.
What about bit-fields in a struct? Wouldn't they automatically be
zeroed correctly too?
--
Keith Thompson (The_Other_Keith) k...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Apr 1 '07 #6

P: n/a
Fr************@googlemail.com wrote:
On Apr 1, 9:09 pm, Keith Thompson <k...@mib.orgwrote:
>>"lovecreatesbea...@gmail.com" <lovecreatesbea...@gmail.comwrites:
>>>Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.


What about bit-fields in a struct? Wouldn't they automatically be
zeroed correctly too?
Bitfields are integer data.
>
>>--
Keith Thompson (The_Other_Keith) k...@mib.org <http://www.ghoti.net/~kst>
Please don't quote signatures.

--
Ian Collins.
Apr 1 '07 #7

P: n/a
Fr************@googlemail.com writes:
On Apr 1, 9:09 pm, Keith Thompson <k...@mib.orgwrote:
>But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

What about bit-fields in a struct? Wouldn't they automatically be
zeroed correctly too?
Bit-fields are integer data.
--
Comp-sci PhD expected before end of 2007
Seeking industrial or academic position *outside California* in 2008
Apr 1 '07 #8

P: n/a
Keith Thompson <ks***@mib.orgwrites:
"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.
I used it when creating bitmaps. I wanted all the bytes initialised to
zero. This meant the background was black. And then I just needed to
draw what I wanted. (Which was a Sierpinkski gasket.) Otherwise I
would have to write extra code to set all the bytes to zero.

--
ilAn
Apr 2 '07 #9

P: n/a
ilan pillemer wrote:
Keith Thompson <ks***@mib.orgwrites:
>"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

I used it when creating bitmaps. I wanted all the bytes initialised to
zero.
"Purely integer data". (IE this is a case Keith covered.)
This meant the background was black. And then I just needed to
draw what I wanted. (Which was a Sierpinkski gasket.) Otherwise I
would have to write extra code to set all the bytes to zero.
Well, yes, one call to rule them all, one call to bind them -- sorry,
that's DNS. I mean, one call to `memset`. (And buried in your
assumed-by-me "makeMyBitmap" function, so written just once anyway.)

--
JUC 2007, submit: http://hpl.hp.com/conferences/juc2007/submission.html
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck Affair/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Apr 2 '07 #10

P: n/a
On Sun, 01 Apr 2007 13:09:03 -0700, Keith Thompson wrote:
"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
>Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate. But
calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.
I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.
Apr 2 '07 #11

P: n/a
J. Sommers said:
On Sun, 01 Apr 2007 13:09:03 -0700, Keith Thompson wrote:
>"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
>>Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate.
But
calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes
sense only for purely integer data.

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.
(a) Strings are sequences of char, and char is an integer type, so
you're not actually disagreeing with him;
(b) strings never need to be NULL-terminated, but they do always need to
be null-terminated.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Apr 2 '07 #12

P: n/a
J. Sommers wrote:
On Sun, 01 Apr 2007 13:09:03 -0700, Keith Thompson wrote:
"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
Do you prefer malloc or calloc?
It's not a matter of preference. Use whichever one is appropriate. But
calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.
Strings cannot ever be NULL-terminated. NULL is a pointer value.
Strings are arrays of characters. And characters, at least in C, are
integer values.

Apr 2 '07 #13

P: n/a
"J. Sommers" <js******@sessrimnir.netwrites:
On Sun, 01 Apr 2007 13:09:03 -0700, Keith Thompson wrote:
>"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
>>Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate. But
calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.
Isn't it a bit of a waste to initialize an entire allocated block
to all-zero-bits just to ensure that a string is null-terminated?

Generally, I ensure that my strings are null-terminated by
null-terminating them.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Apr 2 '07 #14

P: n/a
J. Sommers wrote:
On Sun, 01 Apr 2007 13:09:03 -0700, Keith Thompson wrote:
"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
Do you prefer malloc or calloc?
It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes
sense only for purely integer data.

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

Besides what the others said, this is fairly silly in general. Unless
you're poking individual characters into a char array, this will seldom
save you anything. Almost every string-handling function takes care of
the termination for you, so it's easier and clearer to handle the few
corner cases individually.


Brian
Apr 2 '07 #15

P: n/a
ilan pillemer <il**@pillemer.netwrites:
Keith Thompson <ks***@mib.orgwrites:
>"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate.
But calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

I used it when creating bitmaps. I wanted all the bytes initialised to
zero. This meant the background was black. And then I just needed to
draw what I wanted. (Which was a Sierpinkski gasket.) Otherwise I
would have to write extra code to set all the bytes to zero.
That's one of the (fairly rare) sensible uses of calloc().

But the "extra code to set all the bytes to zero" would be nothing
more than a single call to memset(). If calloc() didn't exist, I
wouldn't miss it.

There are also some subtle points involving very large allocations.
Given calloc(x, y), if the product of x and y won't fit in a size_t,
it's up to the calloc() implementation to handle the "overflow"
sanely. But enough real-world implementations get this wrong that you
can't depend on it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 2 '07 #16

P: n/a
Richard Heathfield wrote:
J. Sommers said:
.... snip ...
>
>I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

(a) Strings are sequences of char, and char is an integer type, so
you're not actually disagreeing with him;
(b) strings never need to be NULL-terminated, but they do always
need to be null-terminated.
Pick, pick, pick nits. nul is the standard name.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Apr 3 '07 #17

P: n/a
CBFalconer wrote:
nul is the standard name.
What do you mean?

The word "nul" isn't in the C standard.

--
pete
Apr 3 '07 #18

P: n/a
On Apr 2, 5:44 pm, CBFalconer <cbfalco...@yahoo.comwrote:
Richard Heathfield wrote:
J. Sommers said:

... snip ...
I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.
(a) Strings are sequences of char, and char is an integer type, so
you're not actually disagreeing with him;
(b) strings never need to be NULL-terminated, but they do always
need to be null-terminated.

Pick, pick, pick nits. nul is the standard name.
Well, if we're getting picky:

- in C it's called the "null character"
- in a lot of character sets it's called "NUL"
- in other character sets it isn't a valid character so doesn't have a
name, and in others it represents a character with a different name -
but I don't think any of these happen to be valid C source or
execution character sets
- I'm not aware of it ever being officially called "nul" or "NULL".

Apr 3 '07 #19

P: n/a
CBFalconer said:
Richard Heathfield wrote:
>J. Sommers said:
... snip ...
>>
>>I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.

(a) Strings are sequences of char, and char is an integer type, so
you're not actually disagreeing with him;
(b) strings never need to be NULL-terminated, but they do always
need to be null-terminated.

Pick, pick, pick nits. nul is the standard name.
Prove it, solely with reference to ISO/IEC 9899.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Apr 3 '07 #20

P: n/a
On Mon, 02 Apr 2007 16:24:53 +0000, J. Sommers wrote:
On Sun, 01 Apr 2007 13:09:03 -0700, Keith Thompson wrote:
>"lovecreatesbea...@gmail.com" <lo***************@gmail.comwrites:
>>Do you prefer malloc or calloc?

It's not a matter of preference. Use whichever one is appropriate. But
calloc() is rarely useful. The main difference is that calloc()
initilizes the allocated memory to all-bits-zero, but that makes sense
only for purely integer data.

I don't know about that. I use it all the time e.g. to deal with
strings that must be NULL-terminated.
Whoa! Nitpicking!

Well, what about the following: You have a structure
with fields consisting of (say) integers and pointers (to whatever you
want.) Those pointers had better be initialized to NULL (it is NULL this
time right?) Is it appropriate to use calloc here?
Apr 3 '07 #21

P: n/a
"J. Sommers" <js******@sessrimnir.netwrites:
[...]
Well, what about the following: You have a structure
with fields consisting of (say) integers and pointers (to whatever you
want.) Those pointers had better be initialized to NULL (it is NULL this
time right?) Is it appropriate to use calloc here?
No. A null pointer is not necessarily represented as all-bits-zero.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 3 '07 #22

P: n/a
On Tue, 03 Apr 2007 02:13:10 -0700, Keith Thompson wrote:
"J. Sommers" <js******@sessrimnir.netwrites: [...]
> Well, what about the following: You have a structure
with fields consisting of (say) integers and pointers (to whatever you
want.) Those pointers had better be initialized to NULL (it is NULL
this time right?) Is it appropriate to use calloc here?

No. A null pointer is not necessarily represented as all-bits-zero.
Good point. Can you provide examples?

Apr 3 '07 #23

P: n/a
J. Sommers wrote:
On Tue, 03 Apr 2007 02:13:10 -0700, Keith Thompson wrote:
>"J. Sommers" <js******@sessrimnir.netwrites: [...]
>> Well, what about the following: You have a structure
with fields consisting of (say) integers and pointers (to whatever you
want.) Those pointers had better be initialized to NULL (it is NULL
this time right?) Is it appropriate to use calloc here?

No. A null pointer is not necessarily represented as all-bits-zero.

Good point. Can you provide examples?
At least one of the Prime series, I am given to understand.

But in any case it doesn't matter; the Standard doesn't say that null
is all-bits-zero and takes care that it isn't implied by other things
it does say, and so we know that code that makes this assumption isn't
portable and we don't do it.

(Unless we must; I've had no examples myself.)

--
The second Jena user conference! http://hpl.hp.com/conferences/juc2007/
"You're not supposed to /think/ about it, /The Beiderbeck Connection/
you're supposed to say NO!" Jill Swinburn

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Apr 3 '07 #24

P: n/a
On Tue, 03 Apr 2007 13:26:46 +0100, Chris Dollin wrote:
J. Sommers wrote:
>On Tue, 03 Apr 2007 02:13:10 -0700, Keith Thompson wrote:
>>"J. Sommers" <js******@sessrimnir.netwrites: [...]
Well, what about the following: You have a structure
with fields consisting of (say) integers and pointers (to whatever
you want.) Those pointers had better be initialized to NULL (it is
NULL this time right?) Is it appropriate to use calloc here?

No. A null pointer is not necessarily represented as all-bits-zero.

Good point. Can you provide examples?

At least one of the Prime series, I am given to understand.

But in any case it doesn't matter; the Standard doesn't say that null is
all-bits-zero and takes care that it isn't implied by other things it
does say, and so we know that code that makes this assumption isn't
portable and we don't do it.
Prime Computers is dead isn't it?

Seriously, while I agree as a matter of principle with what is
being said, I don't think that being dogmatic about it is such a good
idea. Alas, not all C code developed out there is meant to be portable.
Which is why (heresy!) I'll carry on using calloc() the way I described
and live unconcerned in the knowledge that if somebody tries to port it
to a Prime computer (sure, tomorrow) they'll have some work to do.

Apr 3 '07 #25

P: n/a
"J. J. Farrell" wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
.... snip ...
>>
Pick, pick, pick nits. nul is the standard name.

Well, if we're getting picky:

- in C it's called the "null character"
- in a lot of character sets it's called "NUL"
- in other character sets it isn't a valid character so doesn't have a
name, and in others it represents a character with a different name -
but I don't think any of these happen to be valid C source or
execution character sets
- I'm not aware of it ever being officially called "nul" or "NULL".
Look in the char tables for the various possible standard sets.
Yes, it doesn't appear in the C standard.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Apr 3 '07 #26

P: n/a
"J. Sommers" <js******@sessrimnir.netwrites:
On Tue, 03 Apr 2007 13:26:46 +0100, Chris Dollin wrote:
>J. Sommers wrote:
>>On Tue, 03 Apr 2007 02:13:10 -0700, Keith Thompson wrote:
"J. Sommers" <js******@sessrimnir.netwrites: [...]
Well, what about the following: You have a structure
with fields consisting of (say) integers and pointers (to whatever
you want.) Those pointers had better be initialized to NULL (it is
NULL this time right?) Is it appropriate to use calloc here?

No. A null pointer is not necessarily represented as all-bits-zero.

Good point. Can you provide examples?

At least one of the Prime series, I am given to understand.

But in any case it doesn't matter; the Standard doesn't say that null is
all-bits-zero and takes care that it isn't implied by other things it
does say, and so we know that code that makes this assumption isn't
portable and we don't do it.

Prime Computers is dead isn't it?

Seriously, while I agree as a matter of principle with what is
being said, I don't think that being dogmatic about it is such a good
idea. Alas, not all C code developed out there is meant to be portable.
Which is why (heresy!) I'll carry on using calloc() the way I described
and live unconcerned in the knowledge that if somebody tries to port it
to a Prime computer (sure, tomorrow) they'll have some work to do.
*Or* you can write code that doesn't make any assumptions about how
pointers are represented. It's not all that difficult.

For example, you can take advantage of the fact that objects with
static storage duration are implicitly initialized to zero, not
necessarily all-bits-zero (pointers are initialized to null,
floating-point objects are initialized to 0.0). Similarly, if an
explicit initializer doesn't provide values for all members of an
object, the remaining members are initialized to zero, converted to
the appropriate type.

Suppose you have a type "struct mystruct" that contains pointer
members.

const struct mystruct mystruct_zero = { 0 };
struct mystruct *ptr = malloc(COUNT * sizeof *ptr);
/* check result of malloc */
for (i = 0; i < COUNT; i ++) {
ptr[i] = mystruct_zero;
}

And very often, zero-initializing all allocated memory is a waste of
time anyway. Sometimes it's better just to keep track of which
elements haven't been initialized yet.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 3 '07 #27

P: n/a
On Apr 2, 8:12 pm, CBFalconer <cbfalco...@yahoo.comwrote:
"J. J. Farrell" wrote:
CBFalconer <cbfalco...@yahoo.comwrote:

... snip ...
Pick, pick, pick nits. nul is the standard name.
Well, if we're getting picky:
- in C it's called the "null character"
- in a lot of character sets it's called "NUL"
- in other character sets it isn't a valid character so doesn't have a
name, and in others it represents a character with a different name -
but I don't think any of these happen to be valid C source or
execution character sets
- I'm not aware of it ever being officially called "nul" or "NULL".

Look in the char tables for the various possible standard sets.
I did, before I posted. Checked dozens of them, starting from
ASCII-1963 through many ASCIIs, GOSTs, JISCII, Thai and Vietnamese
standards, several different EBCIDCs and Soviet EBCDIC rip-offs,
several of the base ECMA standards which later became the core ISO
character set standards, ISO 646, ISO 8859, Unicode. I didn't use the
official Standard documents in many cses, but did in several of them.
Yes, I was bored.

Sometimes value 0 is undefined, other times it represents some other
character. In most cases it has what is variously described as an
acronym, abbreviation, or name of "NUL". In the important modern
standards, "NUL" is the short form, and the English form of the
character name is "NULL". I never saw it called "nul".

So the correct thing to call it in C is the "null character". With the
added restriction that we're thinking in terms of the modern Standard
character sets, it is reasonable to call it both "NUL" and "NULL". The
latter would be a confusing and unfortunate choice in a C context for
obvious reasons.

Apr 5 '07 #28

P: n/a
In article <pa*********************@sessrimnir.net>,
J. Sommers <js******@sessrimnir.netwrote:
> Prime Computers is dead isn't it?
How could you tell?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Apr 5 '07 #29

P: n/a
In article <b-******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Pick, pick, pick nits. nul is the standard name.
>Prove it, solely with reference to ISO/IEC 9899.
ISO/IEC 9899 refers normatively to ISO 646-1983 which uses the name
NUL (or nul, case is not significant) for the character with code 0.

Point for especially pedantic pedants: determine whether normative
reference in ISO standards is defined to be equivalent to textual
inclusion.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Apr 5 '07 #30

P: n/a
Richard Tobin wrote:
In article <pa*********************@sessrimnir.net>,
J. Sommers <js******@sessrimnir.netwrote:

>> Prime Computers is dead isn't it?


How could you tell?

-- Richard
Wikipedia? According to http://en.wikipedia.org/wiki/Prime_Computer,
Prime Computers died 15 years ago.

Are there still computers made by Prime running somewhere? Hard to tell,
but that's not really important. If Prime is/was the only example of
computers with NULL != all bits zero, we either need more examples or it
is safe to assume that one can use calloc() to zero out pointers.

Bjrn

--
Looking for an embeddable web server?
http://www.metasystems.no/products/h...der/index.html
Apr 5 '07 #31

P: n/a
Richard Tobin said:
In article <b-******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>Pick, pick, pick nits. nul is the standard name.
>>Prove it, solely with reference to ISO/IEC 9899.

ISO/IEC 9899 refers normatively to ISO 646-1983 which uses the name
NUL (or nul, case is not significant) for the character with code 0.
It can be argued that the reference is not normative, since it occurs in
Section 2, Normative References, which is not explicitly described as
normative by any normative part of the Standard.
Point for especially pedantic pedants: determine whether normative
reference in ISO standards is defined to be equivalent to textual
inclusion.
Well, that's my fall-back position. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Apr 5 '07 #32

P: n/a
"B. Augestad" <bo*@metasystems.nowrites:
Richard Tobin wrote:
>In article <pa*********************@sessrimnir.net>,
J. Sommers <js******@sessrimnir.netwrote:
>> Prime Computers is dead isn't it?
How could you tell?
-- Richard

Wikipedia? According to http://en.wikipedia.org/wiki/Prime_Computer,
Prime Computers died 15 years ago.

Are there still computers made by Prime running somewhere? Hard to
tell, but that's not really important. If Prime is/was the only
example of computers with NULL != all bits zero, we either need more
examples or it is safe to assume that one can use calloc() to zero out
pointers.
Since the standard makes no such guarantee, a new platform could come
out tomorrow with null pointers having some representation other than
all-bits-zero. Those of us who have avoided making any assumptions
about pointer representation will be able to port our code to the new
platform with no problem (at least not in that area).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 5 '07 #33

P: n/a
"B. Augestad" wrote:
>
.... snip ...
>
Are there still computers made by Prime running somewhere? Hard
to tell, but that's not really important. If Prime is/was the
only example of computers with NULL != all bits zero, we either
need more examples or it is safe to assume that one can use
calloc() to zero out pointers.
Anything running the UCSD (scud) version of a P-code interpreter.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

--
Posted via a free Usenet account from http://www.teranews.com

Apr 7 '07 #34

P: n/a
"B. Augestad" wrote:
... snip ...

Are there still computers made by Prime running somewhere? Hard
to tell, but that's not really important. If Prime is/was the
only example of computers with NULL != all bits zero, we either
need more examples or it is safe to assume that one can use
calloc() to zero out pointers.
While it may be "safe" to assume that "I am not likely to port my code
to a system in which NULL is not all-bits-zero", you can't say that in
the general sense as far as C is concerned.

BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Apr 9 '07 #35

P: n/a
Kenneth Brody wrote:
"B. Augestad" wrote:
>
... snip ...
>
Are there still computers made by Prime running somewhere? Hard
to tell, but that's not really important. If Prime is/was the
only example of computers with NULL != all bits zero, we either
need more examples or it is safe to assume that one can use
calloc() to zero out pointers.
The TenDRA compiler can use either 0x00000000 or 0x55555555 as the
null pointer representation on x86, depending on the compiler options.
(The system libraries need to be built with the same setting as user
programs, of course.)
While it may be "safe" to assume that "I am not likely to port my code
to a system in which NULL is not all-bits-zero", you can't say that in
the general sense as far as C is concerned.

BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)
There's nothing in the C standard that prohibits it. It would be a
pointless complication for both the implementor and the user, but it
would be valid.

Apr 9 '07 #36

P: n/a
Harald van Dijk wrote:
Kenneth Brody wrote:
>>>"B. Augestad" wrote:

... snip ...

Are there still computers made by Prime running somewhere? Hard
to tell, but that's not really important. If Prime is/was the
only example of computers with NULL != all bits zero, we either
need more examples or it is safe to assume that one can use
calloc() to zero out pointers.


The TenDRA compiler can use either 0x00000000 or 0x55555555 as the
null pointer representation on x86, depending on the compiler options.
(The system libraries need to be built with the same setting as user
programs, of course.)

>>While it may be "safe" to assume that "I am not likely to port my code
to a system in which NULL is not all-bits-zero", you can't say that in
the general sense as far as C is concerned.

BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)


There's nothing in the C standard that prohibits it. It would be a
pointless complication for both the implementor and the user, but it
would be valid.
Are you sure? C99 §6.3.2.3#3 states:
An integer constant expression with the value 0, or such an expression
cast to type void *, is called a null pointer constant.55) If a null
pointer constant is converted to a pointer type, the resulting pointer,
called a null pointer, is guaranteed to compare unequal to a pointer to
any object or function.

§7.17 #3
The macros are NULL which expands to an implementation-defined null
pointer constant;

So NULL must be either 0 or "(void*)0". &MyNullAddress isn't an integer
constant expression, is it?

Bjørn

--
Looking for an embeddable web server?
http://www.metasystems.no/products/h...der/index.html
Apr 9 '07 #37

P: n/a
B. Augestad wrote:
Harald van Dijk wrote:
Kenneth Brody wrote:
>>"B. Augestad" wrote:

... snip ...

Are there still computers made by Prime running somewhere? Hard
to tell, but that's not really important. If Prime is/was the
only example of computers with NULL != all bits zero, we either
need more examples or it is safe to assume that one can use
calloc() to zero out pointers.

The TenDRA compiler can use either 0x00000000 or 0x55555555 as the
null pointer representation on x86, depending on the compiler options.
(The system libraries need to be built with the same setting as user
programs, of course.)

>While it may be "safe" to assume that "I am not likely to port my code
to a system in which NULL is not all-bits-zero", you can't say that in
the general sense as far as C is concerned.

BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)

There's nothing in the C standard that prohibits it. It would be a
pointless complication for both the implementor and the user, but it
would be valid.

Are you sure? C99 §6.3.2.3#3 states:
An integer constant expression with the value 0, or such an expression
cast to type void *, is called a null pointer constant.55) If a null
pointer constant is converted to a pointer type, the resulting pointer,
called a null pointer, is guaranteed to compare unequal to a pointer to
any object or function.

§7.17 #3
The macros are NULL which expands to an implementation-defined null
pointer constant;

So NULL must be either 0 or "(void*)0". &MyNullAddress isn't an integer
constant expression, is it?
I read Kenneth Brody's post as saying NULL would compare equal to
&MyNullAddress, not that it would be defined as &MyNullAddress. I also
assumed that he meant &__MyNullAddress or similar.

And as a side note, (1 - 1) or any other integer constant expression
evaluating to 0 is a valid definition of NULL. Also, (void*)0 is not a
valid definition of NULL, because it is not properly parenthesised.

Apr 9 '07 #38

P: n/a
Kenneth Brody <ke******@spamcop.netwrites:
>"B. Augestad" wrote:
>
... snip ...
>
Are there still computers made by Prime running somewhere? Hard
to tell, but that's not really important. If Prime is/was the
only example of computers with NULL != all bits zero, we either
need more examples or it is safe to assume that one can use
calloc() to zero out pointers.

While it may be "safe" to assume that "I am not likely to port my code
to a system in which NULL is not all-bits-zero", you can't say that in
the general sense as far as C is concerned.

BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)
The NULL macro "expands to an implementation-defined null pointer
constant" (C99 7.17p3).

The term "null pointer constant" is defined in C99 6.3.2.3p3:

An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.

"((void*)&MyNullAddress)" doesn't qualify. Furthermore, a "null
pointer" (as distinct from a "null pointer constant") "is guaranteed
to compare unequal to a pointer to any object or function";
"((void*)&MyNullAddress)" fails on that count as well.

Although C99 6.6p10 says:

An implementation may accept other forms of constant expressions.

But of course the conversion of the integer constant 0 to a pointer
type yields an implementation-specific pointer representation, and I
believe that representation can legitimately vary from one execution
of a program to another, as long as it's always treated as a null
pointer within each execution.

Note that the "%p" format used by fprintf() and fscanf() doesn't
restrict the implementation's flexibility here; the converted value is
required to work only during the same program exexution, and there's
no stated exception for null pointers.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 9 '07 #39

P: n/a
>So NULL must be either 0 or "(void*)0". &MyNullAddress isn't an integer
>constant expression, is it?
No, but 0 or (void *)0 in a pointer context may have the same bit pattern
as &MyNullAddress (e.g. 0xdeadbeef).

True, you can't have:

#define NULL (&MyNullAddress)

You possibly could have:

#define NULL (&__MyNullAddress)
where __MyNullAddress has some compiler magic associated with an implicit
definition of it.
Apr 9 '07 #40

P: n/a
Keith Thompson wrote:
>
Kenneth Brody <ke******@spamcop.netwrites:
[...]
BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)

The NULL macro "expands to an implementation-defined null pointer
constant" (C99 7.17p3).

The term "null pointer constant" is defined in C99 6.3.2.3p3:

An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
But, if the 6.3.2.3p3 definition of "null pointer constant" is "an
integer constant expression with the value 0 .. cast to type void *",
then why does 7.17p3 say that NULL "expand to an implementation-
defined null pointer constant"? If it must be zero, why say that is
is "implementation-defined"? Why not say it is "((void *)0)"?

Doesn't 6.3.2.3p3 say that zero, cast to void * is _a_ null pointer
constant? It doesn't say that no other void * can be a null pointer
constand, does it?
"((void*)&MyNullAddress)" doesn't qualify. Furthermore, a "null
pointer" (as distinct from a "null pointer constant") "is guaranteed
to compare unequal to a pointer to any object or function";
"((void*)&MyNullAddress)" fails on that count as well.
What if __MyNullAddress isn't a real object, but a magic name? Or
perhaps &__MyNullAddress doesn't point to any object. Perhaps it is
magically placed outside the address space of the current process.
Although C99 6.6p10 says:

An implementation may accept other forms of constant expressions.

But of course the conversion of the integer constant 0 to a pointer
type yields an implementation-specific pointer representation, and I
believe that representation can legitimately vary from one execution
of a program to another, as long as it's always treated as a null
pointer within each execution.

Note that the "%p" format used by fprintf() and fscanf() doesn't
restrict the implementation's flexibility here; the converted value is
required to work only during the same program exexution, and there's
no stated exception for null pointers.
Of course, I'm not saying that it necessarily makes sense to do
such strange things, but perhaps an all-bits-zero pointer is a valid
address as far as the hardware is concerned, and you wanted to make
sure that dereferencing NULL would trigger a hardware trap. Perhaps
the way to do that would be to have &__MyNullAddress evaluate to the
start of the next 4K boundary after the end of the initial stack
pointer?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Apr 10 '07 #41

P: n/a
Kenneth Brody <ke******@spamcop.netwrites:
Keith Thompson wrote:
>Kenneth Brody <ke******@spamcop.netwrites:
[...]
BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)

The NULL macro "expands to an implementation-defined null pointer
constant" (C99 7.17p3).

The term "null pointer constant" is defined in C99 6.3.2.3p3:

An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.

But, if the 6.3.2.3p3 definition of "null pointer constant" is "an
integer constant expression with the value 0 .. cast to type void *",
then why does 7.17p3 say that NULL "expand to an implementation-
defined null pointer constant"? If it must be zero, why say that is
is "implementation-defined"? Why not say it is "((void *)0)"?
The standard intentionally allows implementations some flexibility in
how they define NULL. There are a large (potentially infinite, I
suppose) number of valid null pointer constants. An implementation
could define NULL as any of:

0
0L
('-'-'-')
((void*)0)
((void*)'\0')
((void*)('/'/'/'-'/'/'/'))

(There's a pedantic argument that it can't be a parenthesized
expression, but that's a glitch in the wording of the standard, not
the actual intent.)

As for why this flexibility is permitted, I'm not sure. I suppose
there was some backward compatibility issue, but yes, the standard
*could* have required
#define NULL ((void*)0)
Doesn't 6.3.2.3p3 say that zero, cast to void * is _a_ null pointer
constant? It doesn't say that no other void * can be a null pointer
constand, does it?
Not just zero, but an integer constant expression with the value 0.
Since that's the *definition* of the term "null pointer constant"
(it's in italics) I believe it's intended to be exhaustive.
>"((void*)&MyNullAddress)" doesn't qualify. Furthermore, a "null
pointer" (as distinct from a "null pointer constant") "is guaranteed
to compare unequal to a pointer to any object or function";
"((void*)&MyNullAddress)" fails on that count as well.

What if __MyNullAddress isn't a real object, but a magic name? Or
perhaps &__MyNullAddress doesn't point to any object. Perhaps it is
magically placed outside the address space of the current process.
Sure, you can do all sorts of magic, as long as a program can't tell
the difference. But if __MyNullAddress isn't an object, it doesn't
make much sense to take its address. For "((void*)&MyNullAddress)" to
be a null pointer constant, you'd have to have an extension that
treats "&__MyNullAddress" as an integer constant expression with the
value 0.

As long as you're doing magic, you might as well create a magic null
pointer constant that doesn't require applying the unary "&" operator
to something that isn't really an object.

In fact, if I wanted to enable the compiler to catch incorrect uses of
NULL, I'd probably declare:

enum { __NULL__ = 0 };
#define NULL __NULL__

Even without additional compiler support, this is a legitimate
definition (since __NULL__ is in the implementation's namespace). But
a compiler could recognize any use of __NULL__ in a non-pointer
context, and issue a warning.

[...]
Of course, I'm not saying that it necessarily makes sense to do
such strange things, but perhaps an all-bits-zero pointer is a valid
address as far as the hardware is concerned, and you wanted to make
sure that dereferencing NULL would trigger a hardware trap. Perhaps
the way to do that would be to have &__MyNullAddress evaluate to the
start of the next 4K boundary after the end of the initial stack
pointer?
Sure, you could do something like that, but it's not necessary to
create a magic pseudo-object. Any null pointer constant, evaluated in
a pointer context, yields a null pointer value. This:

void *ptr = 0;

*must* set ptr to a null pointer, regardless of how a null pointer is
represented. Adding magic to be used in the definition of the NULL
macro doesn't help for null pointer constants that don't use the NULL
macro.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 10 '07 #42

P: n/a
On 5 Apr, 02:59, "J. J. Farrell" <j...@bcs.org.ukwrote:
On Apr 2, 8:12 pm, CBFalconer <cbfalco...@yahoo.comwrote:
"J. J. Farrell" wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
... snip ...
>Pick, pick, pick nits. nulis the standard name.
Well, if we're getting picky:
- in C it's called the "null character"
- in a lot of character sets it's called "NUL"
- in other character sets it isn't a valid character so doesn't have a
name, and in others it represents a character with a different name -
but I don't think any of these happen to be valid C source or
execution character sets
- I'm not aware of it ever being officially called "nul" or "NULL".
Look in the char tables for the various possible standard sets.

I did, before I posted. Checked dozens of them, starting from
ASCII-1963 through many ASCIIs, GOSTs, JISCII, Thai and Vietnamese
standards, several different EBCIDCs and Soviet EBCDIC rip-offs,
several of the base ECMA standards which later became the core ISO
character set standards, ISO 646, ISO 8859, Unicode. I didn't use the
official Standard documents in many cses, but did in several of them.
Yes, I was bored.

Sometimes value 0 is undefined, other times it represents some other
character. In most cases it has what is variously described as an
acronym, abbreviation, or name of "NUL". In the important modern
standards, "NUL" is the short form, and the English form of the
character name is "NULL". I never saw it called "nul".

So the correct thing to call it in C is the "null character". With the
added restriction that we're thinking in terms of the modern Standard
character sets, it is reasonable to call it both "NUL" and "NULL". The
latter would be a confusing and unfortunate choice in a C context for
obvious reasons.
#include <stdlib.h>
#include <stdio.h>
#define NUL '\0'
int main(void)
{
if (NUL == (char)NULL && NULL == (void *)NUL)
puts("Why?");
if (NULL == NUL)
puts("They're quite the same...");
if (sizeof NUL == sizeof(int)) {
puts("Remember that character constants have type int (FAQ
8.9).");
puts("So there isn't any difference between \'\\0\' and 0.");
}
puts("On some systems, NULL is defined as 0, rather than (void
*)0.");
if (sizeof(void *) != sizeof(int)) {
if (sizeof NULL == sizeof(int))
puts("Yours is one of them.");
else
puts("Yours isn't one of them.");
} else
puts("I can't tell wheter yours is one of them.");
puts("On these systems, there is no difference between NULL and 0,
either.");
/*if (sizeof NULL == sizeof NUL && (NULL ^ NUL) == 0x0000)
* puts("On your system, there's no f***ing difference between NULL
and"
* "NUL."); */
/* On systems where NULL is defined as (void *)0 the if statement in
the
* comment above won't compile. */
puts("Even on those systems, if you want your code to be human
readable,");
puts("you should use \'\\0\' for characters and NULL for
pointers.");
puts("But that's just a matter of style: you could simply use 0 for
both.");
return 0;
}

Apr 13 '07 #43

P: n/a
ar******@email.it wrote:
puts("On some systems, NULL is defined as 0, rather than (void
*)0.");
if (sizeof(void *) != sizeof(int)) {
if (sizeof NULL == sizeof(int))
puts("Yours is one of them.");
sizeof NULL != sizeof(void *) only means that NULL is not defined as
((void *) 0), not that it is defined as 0. #define NULL 0L can make
sense for some implementations.

Apr 13 '07 #44

P: n/a
Harald van Dijk wrote, On 13/04/07 17:38:
ar******@email.it wrote:
> puts("On some systems, NULL is defined as 0, rather than (void
*)0.");
if (sizeof(void *) != sizeof(int)) {
if (sizeof NULL == sizeof(int))
puts("Yours is one of them.");

sizeof NULL != sizeof(void *) only means that NULL is not defined as
((void *) 0), not that it is defined as 0. #define NULL 0L can make
sense for some implementations.
Whilst it is legal, I can't see what advantage it gives. After all, the
compiler would still have to be able to cope with a plain 0.
--
Flash Gordon
Apr 13 '07 #45

P: n/a

"Harald van D?k" <tr*****@gmail.comha scritto nel messaggio
news:11*********************@y5g2000hsa.googlegrou ps.com...
ar******@email.it wrote:
> puts("On some systems, NULL is defined as 0, rather than (void
*)0.");
if (sizeof(void *) != sizeof(int)) {
if (sizeof NULL == sizeof(int))
puts("Yours is one of them.");

sizeof NULL != sizeof(void *) only means that NULL is not defined as
((void *) 0), not that it is defined as 0. #define NULL 0L can make
sense for some implementations.
My program would then print "Yours isn't one of them." [i.e. of those who
#define NULL 0], supposing sizeof(long) sizeof(int) (if it isn't it makes
no sense to #define NULL 0L) in the case sizeof(void *) != sizeof(int), and
"I can't tell wheter yours is one of them.", which can't be wrong,
otherwise.

The only error is I should've written "...rather than for example (void
*)0." instead of "...rather than (void *)0."
Apr 14 '07 #46

P: n/a
Army1987 wrote:
"Harald van D?k" <tr*****@gmail.comha scritto nel messaggio
news:11*********************@y5g2000hsa.googlegrou ps.com...
ar******@email.it wrote:
puts("On some systems, NULL is defined as 0, rather than (void
*)0.");
if (sizeof(void *) != sizeof(int)) {
if (sizeof NULL == sizeof(int))
puts("Yours is one of them.");
sizeof NULL != sizeof(void *) only means that NULL is not defined as
((void *) 0), not that it is defined as 0. #define NULL 0L can make
sense for some implementations.

My program would then print "Yours isn't one of them." [i.e. of those who
#define NULL 0], supposing sizeof(long) sizeof(int) (if it isn't it makes
no sense to #define NULL 0L)
I actually answered that already in another message: headers can be
shared between systems where sizeof(long) sizeof(int) and systems
where sizeof(long) == sizeof(int).

Apr 14 '07 #47

This discussion thread is closed

Replies have been disabled for this discussion.