far pointers

[Harsimran]

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

 

[Chris Torek]

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

 

[Joona I Palaste]

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.

 

[Mabden]

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

 

[Jens.Toerring]

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

 

[pete]

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.

 

[Emmanuel Delahaye]

pete wrote on 12/08/04 :

It may have something to do with Borland.

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

 

[CBFalconer]

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.

 

[CBFalconer]

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

 

[Arthur J. O'Dwyer]

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]

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

 

[Thomas Matthews]

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

pete wrote on 12/08/04 :



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

or in *286* compatible protected mode.

 

[Michael Wojcik]

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().[/QUOTE]

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 (e-mail address removed)

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]

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]

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 (e-mail address removed)

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

 

[CBFalconer]

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

 

[Joona I Palaste]

^^^^^^^ ^^^^^^^
accepts

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

 

[CBFalconer]

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.

 

[CBFalconer]

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