far pointers

[Jens.Toerring]

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

 

[Mark McIntyre]

I'd rather be hammered than wrenched...

Coconut sauce???

Chicken Korma.

 

[Flash Gordon]

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"[/QUOTE]

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.

 

[Jens.Toerring]

On 12 Aug 2004 21:07:05 GMT
(e-mail address removed)-berlin.de wrote:

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.

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

 

[Edd]

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.
</>

 

[Chris Torek]

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

 

[CBFalconer]

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.

 

[CBFalconer]

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

 

[Jens.Toerring]

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

 

[Harsimran]

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

 

[Flash Gordon]

On 13 Aug 2004 04:57:51 -0700
(e-mail address removed) (Harsimran) wrote:

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.

 

[Joona I Palaste]

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?

 

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

 

[Default User]

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]

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.

 

[Stan Milam]

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.