far pointers

[Harsimran]

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

[Jens.Toerring]

CBFalconer <cb********@yah oo.com> wrote:

Michael Wojcik wrote:

CBFalconer <cb********@yah oo.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***********@p hysik.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_glo bal.net> wrote:

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

In article <news:b8******* *************** ****@posting.go ogle.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***********@p hysik.fu-berlin.de wrote:

CBFalconer <cb********@yah oo.com> wrote:

Michael Wojcik wrote:

CBFalconer <cb********@yah oo.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***********@p hysik.fu-berlin.de wrote:

CBFalconer <cb********@yah oo.com> wrote:

> Michael Wojcik wrote:
>> CBFalconer <cb********@yah oo.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***********@p hysik.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
implementationd efined:
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.p ol.co.uk>
Edd <ed*@NOSPAMHERE nunswithguns.ne t> 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***********@p hysik.fu-berlin.de wrote:

CBFalconer <cb********@yah oo.com> wrote:

Michael Wojcik wrote:

CBFalconer <cb********@yah oo.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********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[CBFalconer]

Je***********@p hysik.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********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Jens.Toerring]

CBFalconer <cb********@yah oo.com> wrote:

Je***********@p hysik.fu-berlin.de wrote:

CBFalconer <cb********@yah oo.com> wrote:

> Michael Wojcik wrote:
>> CBFalconer <cb********@yah oo.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***********@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de