far pointers

[Harsimran]

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?

[Joona I Palaste]

Harsimran <sa************@yahoo.co.in> scribbled the following:

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?

Far pointers are not an ISO standard C concept and are thus off-topic
here. There are two differences between malloc and calloc:
1) malloc excepts one parameter, calloc excepts two. The size that
calloc allocates is the parameters multiplied together.
2) calloc automatically zeroes the allocated memory, malloc does not.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"How can we possibly use sex to get what we want? Sex IS what we want."
- Dr. Frasier Crane

[Chris Torek]

In article <news:b8**************************@posting.google. com>
Harsimran <sa************@yahoo.co.in> wrote:

Can any one explain what are far pointers ...
There are no such things. (See the comp.lang.c FAQ, question 19.40d.)
and what is the difference between malloc and calloc .Which is better ?

Which is better, chocolate or strawberry; coconut or soy sauce;
a hammer or a wrench?

A call of the form malloc(n) returns either NULL (failure) or a
pointer to the first of n contiguous bytes. A call of the form
calloc(nitems, size) returns either NULL (failure) or a pointer
to the first of nitems*size contiguous bytes, after also calling
memset() to set all those bytes to '\0'.

If you need bytes pre-set to '\0' you can use calloc(); if you just
need bytes, use malloc().
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Mabden]

"Chris Torek" <no****@torek.net> wrote in message
news:cf********@news3.newsguy.com...

In article <news:b8**************************@posting.google. com>
Harsimran <sa************@yahoo.co.in> wrote:

and what is the difference between malloc and calloc .Which is better ?
Which is better, chocolate or strawberry; coconut or soy sauce;
a hammer or a wrench?

I'd rather be hammered than wrenched...

Coconut sauce???
If you need bytes pre-set to '\0' you can use calloc(); if you just
need bytes, use malloc().

Right, if you are going to malloc() some space then set it all to zero, you
might as well just use calloc(). This can sometimes be the "coward's way
out". If you don't think you can handle using your memory properly, and have
errors in calculating addresses where you are "one off", it's nice to have
the safety net of a zeroed out chunk of memory - no random values. For
instance, when storing strings in malloc'ed memory, if you forget the
terminating '\0', the calloc assures it is already there. So what I'm saying
is calloc() can hide subtle bugs and overruns, so the program may work, but
still have bugs.
I sometimes used calloc in beginning development, to get going, and switched
back to malloc to find bugs and overruns for the real code. But that was a
long time ago - now I want to know right away.

Can anyone come up with a good reason to zero out "raw" memory before you've
even used it? ...maybe to make sure there are zeroes in the empty
byte-aligned null space???

--
Mabden
p.s. I've been wrong before...

[Jens.Toerring]

Mabden <mabden@sbc_global.net> wrote:

Can anyone come up with a good reason to zero out "raw" memory before you've
even used it? ...maybe to make sure there are zeroes in the empty
byte-aligned null space???

Needing an array of ints (or long ints) with all elements initialized
to 0 is more or less the only time I use calloc().

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[pete]

Harsimran wrote:

Can any one explain what are far pointers
It may have something to do with Borland.
and what is the difference
between malloc and calloc .Which is better ?

I use calloc when I want to allocate memory filled
with zero value bytes. That's what calloc is for.

--
pete

[Emmanuel Delahaye]

pete wrote on 12/08/04 :

Can any one explain what are far pointers

It may have something to do with Borland.

Not only. It has somehing to do with x86 arch in real mode.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[CBFalconer]

Je***********@physik.fu-berlin.de wrote:

Mabden <mabden@sbc_global.net> wrote:

Can anyone come up with a good reason to zero out "raw" memory
before you've even used it? ...maybe to make sure there are
zeroes in the empty byte-aligned null space???

Needing an array of ints (or long ints) with all elements
initialized to 0 is more or less the only time I use calloc().

While that may work for you, it is not guaranteed by the standard.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

Joona I Palaste wrote:

Harsimran <sa************@yahoo.co.in> scribbled the following:

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?
Far pointers are not an ISO standard C concept and are thus off-topic
here. There are two differences between malloc and calloc:
1) malloc excepts one parameter, calloc excepts two. The size that

^^^^^^^ ^^^^^^^
accepts :-)
calloc allocates is the parameters multiplied together.
2) calloc automatically zeroes the allocated memory, malloc does not.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Arthur J. O'Dwyer]

On Thu, 12 Aug 2004, CBFalconer wrote:

Je***********@physik.fu-berlin.de wrote:

Needing an array of ints (or long ints) with all elements
initialized to 0 is more or less the only time I use calloc().

While that may work for you, it is not guaranteed by the standard.

Amplification (sorry!;) : memsetting an 'int' to zero is not
guaranteed by the Standard to set the actual /value/ of that 'int'
to the integer zero. (But I think there's some debate about that;
I forget the details.) So what Jens is suggesting doesn't work.

However, unsigned types are guaranteed to have pure binary
representations, which means that memsetting an 'unsigned int' to
zero /will/ set its value to the unsigned integer zero! Ditto
'unsigned char', 'unsigned long', et cetera. (And I think ditto
the new C99 fixed-width types: 'int32_t' and 'int_least8_t' and
friends.)

I often use 'calloc' in image processing; for example, to get
a grayscale image of size w*h initialized to black, I'll write

unsigned char *im = calloc(w*h, 1);

So 'calloc' does have its uses; they're just rare.

-Arthur

[Jens.Toerring]

CBFalconer <cb********@yahoo.com> wrote:

Je***********@physik.fu-berlin.de wrote:

Mabden <mabden@sbc_global.net> wrote:

Can anyone come up with a good reason to zero out "raw" memory
before you've even used it? ...maybe to make sure there are
zeroes in the empty byte-aligned null space???
Needing an array of ints (or long ints) with all elements
initialized to 0 is more or less the only time I use calloc().

While that may work for you, it is not guaranteed by the standard.

Mmm. Because there can be platforms where an int with a value
of 0 hasn't all bits set to zero or because there could be
platforms where an int doesn't use all the bits of the bytes
it consists of and an all bits zero initilization of these
bytes could result in a trap representation? Could you tell me
where I find that in the standard? And doesn't that necessarily
mean that using calloc() for anything else than char arrays
(or could '\0' also be something other than all bits zero?)
would be unportable (same for e.g. memset()?)

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Thomas Matthews]

Harsimran wrote:

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?

Far pointers can be discussed in news:comp.arch.embedded.
I'm sure you will get a wide range of answers. The basic
answer is that some processors have special facilities
for addresses that are near to the program counter and
other facilities for address that are far from the
program counter. For portable code, one should refrain
from any pointer quantifications.

As for malloc vs. calloc, I don't know which is "better"
because "better" is an opinionated word. In my 30 years
of programming, I have never used calloc(). If you don't
need the extra features of calloc() then use malloc().
In some applications, the extra features of calloc()
eat up precious processing time or code space.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

[red floyd]

Emmanuel Delahaye wrote:

pete wrote on 12/08/04 :

Can any one explain what are far pointers

It may have something to do with Borland.

Not only. It has somehing to do with x86 arch in real mode.

or in *286* compatible protected mode.

[Michael Wojcik]

In article <cf********@news3.newsguy.com>, Chris Torek <no****@torek.net> writes:

In article <news:b8**************************@posting.google. com>
Harsimran <sa************@yahoo.co.in> wrote:

and what is the difference between malloc and calloc .Which is better ?

If you need bytes pre-set to '\0' you can use calloc(); if you just
need bytes, use malloc().

IMHO, calloc is better avoided. Since all-bits-zero isn't guaranteed
to be meaningful, much less what the programmer likely expected, for
floating-point and pointer types, it's of less utility than it might
seem. Also, I've seen a lot of code that uses calloc and then goes
on to initialize the entire allocated area anyway, so calloc's zero-
fill is wasted.

In other words, calloc saves you a multiplication and a memset; the
former can trivially be done in the equivalent malloc call, and the
latter may not be useful (and can trivially be done after the malloc
call, if it succeeds).

--
Michael Wojcik mi************@microfocus.com

I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_

[Michael Wojcik]

In article <41***************@yahoo.com>, CBFalconer <cb********@yahoo.com> writes:

Je***********@physik.fu-berlin.de wrote:

Mabden <mabden@sbc_global.net> wrote:

Needing an array of ints (or long ints) with all elements
initialized to 0 is more or less the only time I use calloc().

While that may work for you, it is not guaranteed by the standard.

Isn't it? I thought we had agreed that in effect the only integer
representations that met the standard's requirements were sign-
magnitude, one's-complement, and two's-complement. In all three,
all-bits-zero is a representation for value 0; the first two can
also express "negative zero", but I was under the impression that
the rule requiring same representation for corresponding signed and
unsigned types ruled out "negative zero" as the canonical represen-
tation for value 0.

In short, initializing an array of ints or long ints to all-bits-
zero should, AFAICT, initialize each member of the array to value
0 on any conforming implementation. What am I missing?

--
Michael Wojcik mi************@microfocus.com

The way things were, were the way things were, and they stayed that way
because they had always been that way. -- Jon Osborne

[CBFalconer]

"Arthur J. O'Dwyer" wrote:

.... snip ...
However, unsigned types are guaranteed to have pure binary
representations, which means that memsetting an 'unsigned int' to
zero /will/ set its value to the unsigned integer zero! Ditto
'unsigned char', 'unsigned long', et cetera. (And I think ditto
the new C99 fixed-width types: 'int32_t' and 'int_least8_t' and
friends.)

I often use 'calloc' in image processing; for example, to get
a grayscale image of size w*h initialized to black, I'll write

unsigned char *im = calloc(w*h, 1);

So 'calloc' does have its uses; they're just rare.

I believe there is a movement for an addendum to C99 to insist on
that all bytes zero representation of integer zeroes. AFAIK there
are no installations extant where it doesn't work.

The real trap is using it to initialize a pointer array to NULLs.
Also floating point.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Michael Wojcik]

In article <Pi**********************************@unix48.andre w.cmu.edu>, "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

However, unsigned types are guaranteed to have pure binary
representations, which means that memsetting an 'unsigned int' to
zero /will/ set its value to the unsigned integer zero! Ditto
'unsigned char', 'unsigned long', et cetera. (And I think ditto
the new C99 fixed-width types: 'int32_t' and 'int_least8_t' and
friends.)

The signed integer types are required to have the same representation
as their corresponding unsigned types for values that both types can
represent (C99 6.1.2.5).

Thus the signed integer types' zeros must also be all-bits-zero.

Further, the "pure binary numeration system" requirement applies to
all integral types, not just unsigned ones (also 6.1.2.5).

--
Michael Wojcik mi************@microfocus.com

Therefore, it is possible to enjoy further by using under the
Netscape 2.0. However, Netscape will hangup at sometimes. You
should give it up. -- roro

[Joona I Palaste]

CBFalconer <cb********@yahoo.com> scribbled the following:

Joona I Palaste wrote:

Harsimran <sa************@yahoo.co.in> scribbled the following:

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?

Far pointers are not an ISO standard C concept and are thus off-topic
here. There are two differences between malloc and calloc:
1) malloc excepts one parameter, calloc excepts two. The size that

^^^^^^^ ^^^^^^^
accepts :-)

I actually meant "expects". But thanks for pointing out my misspelling
anyway.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"This isn't right. This isn't even wrong."
- Wolfgang Pauli

[CBFalconer]

Michael Wojcik wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

However, unsigned types are guaranteed to have pure binary
representations, which means that memsetting an 'unsigned int' to
zero /will/ set its value to the unsigned integer zero! Ditto
'unsigned char', 'unsigned long', et cetera. (And I think ditto
the new C99 fixed-width types: 'int32_t' and 'int_least8_t' and
friends.)

The signed integer types are required to have the same representation
as their corresponding unsigned types for values that both types can
represent (C99 6.1.2.5).

Thus the signed integer types' zeros must also be all-bits-zero.

Further, the "pure binary numeration system" requirement applies to
all integral types, not just unsigned ones (also 6.1.2.5).

That does not follow. Integers can have trap bits. For example a
machine with 18 bit words, 9 bit bytes could have 2 trap bits in
integers, one marking it initialized, and one for parity. These
don't enter into the value (which must have at least 16 bits).
The hardware could trap on various conditions caused by an
'all-bits-zero' setting.

In fact many such machines exist, using 8 bit bytes with a parity
bit added. However the parity would not be user controlled or
read, but it could be random on uninitialized memory. ECC memory
is another such. Here proper use requires that machine
initialization ignore the error checks and set up the parity or
ECC syndrome.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

Michael Wojcik wrote:

CBFalconer <cb********@yahoo.com> writes:
.... snip ...
Isn't it? I thought we had agreed that in effect the only integer
representations that met the standard's requirements were sign-
magnitude, one's-complement, and two's-complement. In all three,
all-bits-zero is a representation for value 0; the first two can
also express "negative zero", but I was under the impression that
the rule requiring same representation for corresponding signed and
unsigned types ruled out "negative zero" as the canonical represen-
tation for value 0.

In short, initializing an array of ints or long ints to all-bits-
zero should, AFAICT, initialize each member of the array to value
0 on any conforming implementation. What am I missing?

Those are value bits. There may be trap bits, which are forbidden
in unsigned char objects.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Jens.Toerring]

CBFalconer <cb********@yahoo.com> wrote:

Michael Wojcik wrote:

CBFalconer <cb********@yahoo.com> writes:
... snip ...

Isn't it? I thought we had agreed that in effect the only integer
representations that met the standard's requirements were sign-
magnitude, one's-complement, and two's-complement. In all three,
all-bits-zero is a representation for value 0; the first two can
also express "negative zero", but I was under the impression that
the rule requiring same representation for corresponding signed and
unsigned types ruled out "negative zero" as the canonical represen-
tation for value 0.

In short, initializing an array of ints or long ints to all-bits-
zero should, AFAICT, initialize each member of the array to value
0 on any conforming implementation. What am I missing?

Those are value bits. There may be trap bits, which are forbidden
in unsigned char objects.

But wouldn't it be reasonable to assume that "The space is initialized
to all bits zero." sentence from the standard about calloc() only
refers to these value bits? They are the only ones the programmer is
ever going to "see" and there's the footnote explicitely warning "Note
that this need not be the same as the representation of floating-point
zero or a null pointer constant." which I would tend to interpret that
for int's and long int's that problem does not exist.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Mark McIntyre]

On Thu, 12 Aug 2004 08:52:50 GMT, in comp.lang.c , "Mabden"
<mabden@sbc_global.net> wrote:

"Chris Torek" <no****@torek.net> wrote in message
news:cf********@news3.newsguy.com...

In article <news:b8**************************@posting.google. com>
Harsimran <sa************@yahoo.co.in> wrote:

>and what is the difference between malloc and calloc .Which is better ?

Which is better, chocolate or strawberry; coconut or soy sauce;
a hammer or a wrench?

I'd rather be hammered than wrenched...

Coconut sauce???

Chicken Korma.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Flash Gordon]

On 12 Aug 2004 21:07:05 GMT
Je***********@physik.fu-berlin.de wrote:

CBFalconer <cb********@yahoo.com> wrote:

Michael Wojcik wrote:

CBFalconer <cb********@yahoo.com> writes:
... snip ...

Isn't it? I thought we had agreed that in effect the only integer
representations that met the standard's requirements were sign-
magnitude, one's-complement, and two's-complement. In all three,
all-bits-zero is a representation for value 0; the first two can
also express "negative zero", but I was under the impression that
the rule requiring same representation for corresponding signed and
unsigned types ruled out "negative zero" as the canonical represen-
tation for value 0.

In short, initializing an array of ints or long ints to all-bits-
zero should, AFAICT, initialize each member of the array to value
0 on any conforming implementation. What am I missing?

Those are value bits. There may be trap bits, which are forbidden
in unsigned char objects.

But wouldn't it be reasonable to assume that "The space is initialized
to all bits zero." sentence from the standard about calloc() only
refers to these value bits? They are the only ones the programmer is
ever going to "see"

The programmer might access the calloced area as unsigned char, in which
case ALL bits are value bits, so every bit needs to be initialised to 0
in a calloc call. In fact, I have code at work which callocs a buffer
then accesses the data as unsigned char.
and there's the footnote explicitely warning "Note
that this need not be the same as the representation of floating-point
zero or a null pointer constant." which I would tend to interpret that
for int's and long int's that problem does not exist.

The footnotes are not normative text, so that doesn't prove anything
unfortunately.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Jens.Toerring]

Flash Gordon <sp**@flash-gordon.me.uk> wrote:

On 12 Aug 2004 21:07:05 GMT
Je***********@physik.fu-berlin.de wrote:

CBFalconer <cb********@yahoo.com> wrote:

> Michael Wojcik wrote:
>> CBFalconer <cb********@yahoo.com> writes:
>>
> ... snip ...
>>
>> Isn't it? I thought we had agreed that in effect the only integer
>> representations that met the standard's requirements were sign-
>> magnitude, one's-complement, and two's-complement. In all three,
>> all-bits-zero is a representation for value 0; the first two can
>> also express "negative zero", but I was under the impression that
>> the rule requiring same representation for corresponding signed and
>> unsigned types ruled out "negative zero" as the canonical represen-
>> tation for value 0.
>>
>> In short, initializing an array of ints or long ints to all-bits-
>> zero should, AFAICT, initialize each member of the array to value
>> 0 on any conforming implementation. What am I missing?

> Those are value bits. There may be trap bits, which are forbidden
> in unsigned char objects.

But wouldn't it be reasonable to assume that "The space is initialized
to all bits zero." sentence from the standard about calloc() only
refers to these value bits? They are the only ones the programmer is
ever going to "see" The programmer might access the calloced area as unsigned char, in which
case ALL bits are value bits, so every bit needs to be initialised to 0
in a calloc call. In fact, I have code at work which callocs a buffer
then accesses the data as unsigned char. and there's the footnote explicitely warning "Note
that this need not be the same as the representation of floating-point
zero or a null pointer constant." which I would tend to interpret that
for int's and long int's that problem does not exist.

The footnotes are not normative text, so that doesn't prove anything
unfortunately.

Thanks. That of course leaves one wondering why calloc() takes two
arguments at all when it actually can be called safely only in
cases were the second one is 1 - but that could be due to historic
reasons, i.e. it was originally meant to allow initialization of
e.g. int arrays but for some reasons that couldn't be kept that
way.

But then there's still the memset() function. Do the same restrictions
apply as for calloc() or can it be safely used for intitialization of
an int array with zeros? The "into each of the first n characters" bit
seems to hint at the same problem as with calloc()...

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Edd]

Harsimran wrote:

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?

I believe others have answered your question perfectly well, but while we're on
the subject I'd like to ask about something that's been niggling me for a while now.

One of my C programming books (A Book On C 4th edition, Kelley & Pohl) has the
following to say about malloc and calloc (page 663):
void *calloc(size_t n, size_t el_size);
Allocates contiguous space in memory for an array of n elements, with each
element requiring el_size bytes. The space is initialized with all bits set to
zero. A successful call returns the base address of the allocated space;
otherwise, NULL is returned.

void *malloc(size_t size);
Allocates a block in memory consisting of size bytes. The space is not
initialized. A successful call returns the base address of the allocated space;
otherwise, NULL is returned.
The niggle of which I speak is with respect to the "contiguous" part of the
calloc description; is the space allocated by a successful malloc call not
necessarily required to be contiguous?

I don't have a copy of the standard (yet) and so I'd really appreciate it if
someone could clear this up for me. As far as I can see, it would be daft for
malloc-ated space not to be contiguous?

Thanks.

Edd

[Emmanuel Delahaye]

Edd wrote on 13/08/04 :

void *malloc(size_t size);
Allocates a block in memory consisting of size bytes. The space is not
initialized. A successful call returns the base address of the allocated
space; otherwise, NULL is returned.

The niggle of which I speak is with respect to the "contiguous" part of the
calloc description; is the space allocated by a successful malloc call not
necessarily required to be contiguous?

No. Like for calloc() and realloc(), it has to be contiguous and well
aligned.

<ISO/IEC 9899:1999 (E)>
7.20.3 Memory management functions
1 The order and contiguity of storage allocated by successive calls to
the calloc,
malloc, and realloc functions is unspecified. The pointer returned if
the allocation
succeeds is suitably aligned so that it may be assigned to a pointer to
any type of object
and then used to access such an object or an array of such objects in
the space allocated
(until the space is explicitly deallocated). The lifetime of an
allocated object extends
from the allocation until the deallocation. Each such allocation shall
yield a pointer to an
object disjoint from any other object. The pointer returned points to
the start (lowest byte
address) of the allocated space. If the space cannot be allocated, a
null pointer is
returned. If the size of the space requested is zero, the behavior is
implementationdefined:
either a null pointer is returned, or the behavior is as if the size
were some
nonzero value, except that the returned pointer shall not be used to
access an object.
7.20.3.1 The calloc function
Synopsis
1 #include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
Description
2 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.252)
Returns
3 The calloc function returns either a null pointer or a pointer to the
allocated space.
</>

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Chris Torek]

In article <news:cf**********@news7.svr.pol.co.uk>
Edd <ed*@NOSPAMHEREnunswithguns.net> wrote:

... while we're on the subject I'd like to ask about something
that's been niggling me for a while now. One of my C programming books (A Book On C 4th edition, Kelley &
Pohl) has the following to say about malloc and calloc (page 663):
[wording snipped, but calloc()'s description contains the word
"contiguous" while malloc()'s does not]
The niggle of which I speak is with respect to the "contiguous" part of the
calloc description; is the space allocated by a successful malloc call not
necessarily required to be contiguous?

Both return a contiguous memory region.

The calloc() description is "more deserving" of the extra word for
one simple reason: malloc() gets only one parameter -- the number
of bytes to allocate -- while calloc() gets two. Since "there is
no magic" (or was, at least, when C was first being written -- ISO
now allows arbitrary amounts of magic to occur between the compiler
and its Standard C library), a call of the form:

malloc(32)

is unable to tell whether you wanted 8 four-byte objects (e.g.,
malloc(n_obj * sizeof *obj) where n_obj is 8 and sizeof *obj is 4)
or whether you wanted a single 32-byte object (e.g.,
malloc(sizeof *obj2) where sizeof *obj2 is 32). On the other
hand, calloc gets a separate "number of objects" and "size of
each object":

calloc(n_obj, sizeof *obj) /* for the first case */
vs calloc(1, sizeof *obj2) /* for the second case */

Obviously calloc() has more information than malloc() -- so it
might, conceivably, be able to use that to call malloc() N times
instead of just once (and indeed, there was once a cfree() that
was to be used on calloc()'ed memory, and perhaps cfree() might
then call free() N times as well). If calloc() were allowed to
do that, it could get N discontiguous regions, and perhaps
chain them together into a linked list or something.

It does not do that, of course; and you free() the pointers you
get from calloc() just as you free() those from malloc(), so calloc()
just has to multiply its two parameters together (and check for
overflow). But because calloc() has, at first glance, enough
information to malloc() N times, the extra word "contiguous" has
some reason for being there, however weak that reason turns out to
be in the end.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Je***********@physik.fu-berlin.de wrote:

CBFalconer <cb********@yahoo.com> wrote:

Michael Wojcik wrote:

CBFalconer <cb********@yahoo.com> writes:

... snip ...

Isn't it? I thought we had agreed that in effect the only integer
representations that met the standard's requirements were sign-
magnitude, one's-complement, and two's-complement. In all three,
all-bits-zero is a representation for value 0; the first two can
also express "negative zero", but I was under the impression that
the rule requiring same representation for corresponding signed and
unsigned types ruled out "negative zero" as the canonical represen-
tation for value 0.

In short, initializing an array of ints or long ints to all-bits-
zero should, AFAICT, initialize each member of the array to value
0 on any conforming implementation. What am I missing?

Those are value bits. There may be trap bits, which are forbidden
in unsigned char objects.

But wouldn't it be reasonable to assume that "The space is initialized
to all bits zero." sentence from the standard about calloc() only
refers to these value bits? They are the only ones the programmer is
ever going to "see" and there's the footnote explicitely warning "Note
that this need not be the same as the representation of floating-point
zero or a null pointer constant." which I would tend to interpret that
for int's and long int's that problem does not exist.

But calloc initializes bytes. Integers may occupy an integral
number of bytes, but they do NOT have to use all of their bits as
value bits. Admittedly such an actual machine would be unusual
and probably have marketing problems, but it is not foreclosed by
the C standard.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

Je***********@physik.fu-berlin.de wrote:

.... snip ...
But then there's still the memset() function. Do the same restrictions
apply as for calloc() or can it be safely used for intitialization of
an int array with zeros? The "into each of the first n characters" bit
seems to hint at the same problem as with calloc()...

No. It is not presently guaranteed.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Jens.Toerring]

CBFalconer <cb********@yahoo.com> wrote:

Je***********@physik.fu-berlin.de wrote:

CBFalconer <cb********@yahoo.com> wrote:

> Michael Wojcik wrote:
>> CBFalconer <cb********@yahoo.com> writes:
>>
> ... snip ...
>>
>> Isn't it? I thought we had agreed that in effect the only integer
>> representations that met the standard's requirements were sign-
>> magnitude, one's-complement, and two's-complement. In all three,
>> all-bits-zero is a representation for value 0; the first two can
>> also express "negative zero", but I was under the impression that
>> the rule requiring same representation for corresponding signed and
>> unsigned types ruled out "negative zero" as the canonical represen-
>> tation for value 0.
>>
>> In short, initializing an array of ints or long ints to all-bits-
>> zero should, AFAICT, initialize each member of the array to value
>> 0 on any conforming implementation. What am I missing?

> Those are value bits. There may be trap bits, which are forbidden
> in unsigned char objects.

But wouldn't it be reasonable to assume that "The space is initialized
to all bits zero." sentence from the standard about calloc() only
refers to these value bits? They are the only ones the programmer is
ever going to "see" and there's the footnote explicitely warning "Note
that this need not be the same as the representation of floating-point
zero or a null pointer constant." which I would tend to interpret that
for int's and long int's that problem does not exist.

But calloc initializes bytes. Integers may occupy an integral
number of bytes, but they do NOT have to use all of their bits as
value bits. Admittedly such an actual machine would be unusual
and probably have marketing problems, but it is not foreclosed by
the C standard.

Thanks for your (and everyone else's) replies.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Harsimran]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@unix48. andrew.cmu.edu>...

On Thu, 12 Aug 2004, CBFalconer wrote:

Je***********@physik.fu-berlin.de wrote:

Needing an array of ints (or long ints) with all elements
initialized to 0 is more or less the only time I use calloc().

While that may work for you, it is not guaranteed by the standard.

Amplification (sorry!;) : memsetting an 'int' to zero is not
guaranteed by the Standard to set the actual /value/ of that 'int'
to the integer zero. (But I think there's some debate about that;
I forget the details.) So what Jens is suggesting doesn't work.

However, unsigned types are guaranteed to have pure binary
representations, which means that memsetting an 'unsigned int' to
zero /will/ set its value to the unsigned integer zero! Ditto
'unsigned char', 'unsigned long', et cetera. (And I think ditto
the new C99 fixed-width types: 'int32_t' and 'int_least8_t' and
friends.)

I often use 'calloc' in image processing; for example, to get
a grayscale image of size w*h initialized to black, I'll write

unsigned char *im = calloc(w*h, 1);

So 'calloc' does have its uses; they're just rare.

-Arthur

I had gone through three books (just basics ones) but didnt find
memset memmove ect can any one plz explain it .

[Emmanuel Delahaye]

Harsimran wrote on 13/08/04 :

I had gone through three books (just basics ones) but didnt find
memset memmove ect can any one plz explain it .

A good reference for C functions:

http://www.dinkumware.com/refxc.html

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Joona I Palaste]

Harsimran <sa************@yahoo.co.in> scribbled the following:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@unix48. andrew.cmu.edu>...

On Thu, 12 Aug 2004, CBFalconer wrote:

>
> Je***********@physik.fu-berlin.de wrote:
>> Needing an array of ints (or long ints) with all elements
>> initialized to 0 is more or less the only time I use calloc().
>
> While that may work for you, it is not guaranteed by the standard.
Amplification (sorry!;) : memsetting an 'int' to zero is not
guaranteed by the Standard to set the actual /value/ of that 'int'
to the integer zero. (But I think there's some debate about that;
I forget the details.) So what Jens is suggesting doesn't work.

However, unsigned types are guaranteed to have pure binary
representations, which means that memsetting an 'unsigned int' to
zero /will/ set its value to the unsigned integer zero! Ditto
'unsigned char', 'unsigned long', et cetera. (And I think ditto
the new C99 fixed-width types: 'int32_t' and 'int_least8_t' and
friends.)

I often use 'calloc' in image processing; for example, to get
a grayscale image of size w*h initialized to black, I'll write

unsigned char *im = calloc(w*h, 1);

So 'calloc' does have its uses; they're just rare.

I had gone through three books (just basics ones) but didnt find
memset memmove ect can any one plz explain it .

They must be pretty crappy books then. memset is a function for setting
every byte in a range of bytes to a specific value. memmove is for
moving a range of bytes into another location in memory. Does this
answer your question?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Show me a good mouser and I'll show you a cat with bad breath."
- Garfield

[Emmanuel Delahaye]

Joona I Palaste wrote on 13/08/04 :

memmove is for
moving a range of bytes into another location in memory.

Actually, no. memmove() is used to copy bytes in overlapping memory.

char s[] = "hello world";

memmove (s, s + 6, 5);

produces "world world"

Due to overlapping,

/* Don't do that */
memcpy (s, s + 6, 5);

would have produced an Undefined Behaviour.

(I'm quite sure you was aware of that...)

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

[Flash Gordon]

On 13 Aug 2004 04:57:51 -0700
sa************@yahoo.co.in (Harsimran) wrote:

<snip>

I had gone through three books (just basics ones) but didnt find
memset memmove ect can any one plz explain it .

I can offer three possible explanations.

1) The books were bad.
2) The books were aimed only at getting you just about started and
deliberately left out those functions.
3) You didn't read the books very carefully.

I would recommend that you get The C Programming Language 2nd edition by
Kernighan & Ritchie.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Default User]

Edd wrote:

Harsimran wrote:

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?

I believe others have answered your question perfectly well, but while we're on
the subject I'd like to ask about something that's been niggling me for a while now.

One of my C programming books (A Book On C 4th edition, Kelley & Pohl) has the
following to say about malloc and calloc (page 663):

void *calloc(size_t n, size_t el_size);
Allocates contiguous space in memory for an array of n elements, with each
element requiring el_size bytes. The space is initialized with all bits set to
zero. A successful call returns the base address of the allocated space;
otherwise, NULL is returned.

void *malloc(size_t size);
Allocates a block in memory consisting of size bytes. The space is not
initialized. A successful call returns the base address of the allocated space;
otherwise, NULL is returned.

The niggle of which I speak is with respect to the "contiguous" part of the
calloc description; is the space allocated by a successful malloc call not
necessarily required to be contiguous?

Note that the description of malloc() states it returns a "block in
memory". I can't think of any definition of "block" that would allow it
to be non-contiguous. I believe the author just used slightly different
phrasing.
Brian Rodenborn

[CBFalconer]

Joona I Palaste wrote:

Harsimran <sa************@yahoo.co.in> scribbled the following:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:

On Thu, 12 Aug 2004, CBFalconer wrote:
Je***********@physik.fu-berlin.de wrote:

> Needing an array of ints (or long ints) with all elements
> initialized to 0 is more or less the only time I use calloc().

While that may work for you, it is not guaranteed by the standard.

Amplification (sorry!;) : memsetting an 'int' to zero is not
guaranteed by the Standard to set the actual /value/ of that 'int'
to the integer zero. (But I think there's some debate about that;
I forget the details.) So what Jens is suggesting doesn't work.

However, unsigned types are guaranteed to have pure binary
representations, which means that memsetting an 'unsigned int' to
zero /will/ set its value to the unsigned integer zero! Ditto
'unsigned char', 'unsigned long', et cetera. (And I think ditto
the new C99 fixed-width types: 'int32_t' and 'int_least8_t' and
friends.)

I often use 'calloc' in image processing; for example, to get
a grayscale image of size w*h initialized to black, I'll write

unsigned char *im = calloc(w*h, 1);

So 'calloc' does have its uses; they're just rare.

I had gone through three books (just basics ones) but didnt find
memset memmove ect can any one plz explain it .

They must be pretty crappy books then. memset is a function for setting
every byte in a range of bytes to a specific value. memmove is for
moving a range of bytes into another location in memory. Does this
answer your question?

and there is also memcpy() in the same group. Read all their
specifications.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Stan Milam]

Harsimran wrote:

Can any one explain what are far pointers and what is the difference
between malloc and calloc .Which is better ?

Others have answered very well about the difference between malloc and
calloc, but like most C programmers who are anal rententive (myself
included) did not answer your question about far pointers. The only
reference they gave you was that far pointers were off-topic since they
are not ANSI C. Here is the long and short of it.

In the bad old MS-DOS days the X86 processors used 16 bit registers and
pointers which only allowed addressing 64K of memory. Intel included a
cludge where two registers (pointers) could be used to address 1 meg of
memory. The two pointers were called segment and offset respectively.
To address 1 meg the segment address was internally expanded to 20 bits
and shifed left four bits. The offset address was then added to render
the final 20 bit address. Ultimately it was a real mess and fostered a
lot of unportable code. I was so much happier when I started
programming in UNIX and did not have to mess with memory models and far
pointers.

--
Regards,
Stan Milam.
-----------------------------------------------------------------------------
My life is a song. I live to be sung. I sing with all my heart - John
Denver.
-----------------------------------------------------------------------------