malloc vs calloc

[Richard Bos]

No they don't. Often people do not read an entire archive for a problem
they did not even realise existed.

That's their problem.

It _used_ to be considered merely polite to read both a newsgroup's FAQ
and a decent amount of existing posts before posting your first question
on a newsgroup. In this group, for this error, one or two weeks' backlog
would have been more than enough not to make it. But mere politeness is
no longer the done thing; these days, even on Usenet, instant
gratification and a complete lack of one's own intelligent initiative
are /de rigeur/. 't is a pity, but there it is.

Richard

 

[Yevgen Muntyan]

Correction: C++ / C99 style comment

An alternative method might be to check for errno instead:
x = malloc(n * sizeof *x);
if ( !x && errno ) {
/* failure */
}

Broken since you didn't zero errno.

errno = 0;
/* lalala */

Anyway, does C standard require errno set here? Linux (glibc) man page
says Unix98 standard requires it. Posix man page says nothing (except
that errno is set).

Yevgen

 

[Chris Dollin]

An alternative method might be to check for errno instead:
x = malloc(n * sizeof *x);
if ( !x && errno ) {
/* failure */
}

What leads you to believe `malloc` sets `errno` to anything useful,
or to anything at all?

 

[Joachim Schmitz]

This is not enough...

x = malloc(n * sizeof *x);

if ( n && !x ) {
// failure
}

is more portable.

No, it is not, due to a C++ style comment... ;-)
Other than that: yes, the ANSI/ISO Standard states that malloc(0) is allowed
to return either NULL or a pointer to 0 bytes and regards this
implementation defined behavoir.

Bye, Jojo

 

[Joachim Schmitz]

No, it is not, due to a C++ style comment... ;-)

Correction: C++ / C99 style comment

Other than that: yes, the ANSI/ISO Standard states that malloc(0) is
allowed to return either NULL or a pointer to 0 bytes and regards this
implementation defined behavoir.

An alternative method might be to check for errno instead:
x = malloc(n * sizeof *x);
if ( !x && errno ) {
/* failure */
}

Bye, Jojo

 

[Richard Bos]

Sounds like it should be a sister to Moose Jaw, which is far from
anything. Does it have hooligoolians?

Dunno about Goole, but Scunthorpe FC...

Richard

 

[Joachim Schmitz]

What leads you to believe `malloc` sets `errno` to anything useful,
or to anything at all?

The documentation of various systems I'm using. I must admit that I didn't
check the C-standard, but I'm pretty sure POSIX requires errno being set by
malloc in case of errors.
Also I said 'might be', conjunctive ...

Bye, Jojo

 

[Chris Dollin]

The documentation of various systems I'm using. I must admit that I didn't
check the C-standard, but I'm pretty sure POSIX requires errno being set by
malloc in case of errors.

I wouldn't know about POSIX, but C doesn't require that, and I'd rather
avoid something that is POSIX-specific if I can. (At one point I had C
code running under RISC OS, which I believe is POSIX-compliant ...)

Also I said 'might be', conjunctive ...

"Might be", as in "not portably".

 

[Joachim Schmitz]

I wouldn't know about POSIX, but C doesn't require that, and I'd rather
avoid something that is POSIX-specific if I can. (At one point I had C
code running under RISC OS, which I believe is POSIX-compliant ...)


"Might be", as in "not portably".

a) as in "possibly not portable"
b) as portable as the P of POSIX...

Bye, Jojo

 

[Walter Roberson]

I must admit that I didn't
check the C-standard, but I'm pretty sure POSIX requires errno being set by
malloc in case of errors.

Not in ISO 9945-1 / IEEE Std 1003.1 (1990), also known as POSIX.1 .

POSIX.1 defines malloc() as being imported from
ISO/IEC 9899:1990 Information technology - Programming Language C
and does *not* place any additional constraints upon its behaviour.

Possibly a later POSIX placed some constraint upon malloc().

 

[Mark McIntyre]

No they don't. Often people do not read an entire archive for a problem
they did not even realise existed.

This is probably why the usenet ettiquette (which some folks round
here are keen on quoting) requires newbies to LURK before posting.

I would suggest that if you are tired of pointing out such corrections
then you need to take a break from offering advice.

and I suggest you get your sarcasm detector repaired. Ian's question
was rhetorical.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Ian Collins]

This is probably why the usenet ettiquette (which some folks round
here are keen on quoting) requires newbies to LURK before posting.


and I suggest you get your sarcasm detector repaired. Ian's question
was rhetorical.

Maybe we should add the text [MCA] in reply headers for Malloc Cast Alert.

 

[Christopher Layne]

No, it is not, due to a C++ style comment... ;-)
Other than that: yes, the ANSI/ISO Standard states that malloc(0) is allowed
to return either NULL or a pointer to 0 bytes and regards this
implementation defined behavoir.

Bye, Jojo

Which means the code above also produced a memory leak on an allocation of 0
bytes.

 

[Cesar Rabak]

CBFalconer escreveu:

Another valueless foolish post. Into the sin bin you go.

Chuck, are suggesting that a bit of common sense should burn?

 

[Cesar Rabak]

Ian Collins escreveu:

This is probably why the usenet ettiquette (which some folks round
here are keen on quoting) requires newbies to LURK before posting.

and I suggest you get your sarcasm detector repaired. Ian's question
was rhetorical.

Maybe we should add the text [MCA] in reply headers for Malloc Cast Alert.

Or write a robot that detects this code construct and automatically
sends the MCA in full text :-D

 

[J. J. Farrell]

Not in ISO 9945-1 / IEEE Std 1003.1 (1990), also known as POSIX.1 .

POSIX.1 defines malloc() as being imported from
ISO/IEC 9899:1990 Information technology - Programming Language C
and does *not* place any additional constraints upon its behaviour.

Possibly a later POSIX placed some constraint upon malloc().

[OT] The current POSIX requires that errno be set for malloc() errors
- but not in the case of malloc(0). This came with the merging in of
the X/Open standards.

 

[Flash Gordon]

Joachim Schmitz wrote, On 03/02/07 09:39:
Approximation of line snipped at some point:
n = malloc(x * sizeof *n);

Please explain why.

The assumption is that if x==0 and the malloc succeeds then the memory
is never freed. Now, it may seem like leaking 0 bites does not matter,
but there is likely to be some control data as well so the actual amount
of memory used is likely to be non-zero. Even if it really is true that
no memory is used then you are still wasting address space (pointers are
a finite size so there are only a finite number of unique pointers. Of
course, the code for failure might free the pointer since freeing a null
pointer is allowed and harmless.

Personally I have a malloc wrapper (for other reasons) which amongst
other things checks for 0 size allocations and returns a null pointer
for them. If I wanted it to return pointers (there are reasons one
might) then I would change the wrapper to convert 0 size allocations to
1 byte allocations.

 

[Joachim Schmitz]

Which means the code above also produced a memory leak on an allocation of
0
bytes.

Please explain why.

Bye, Jojo

 

[Clark S. Cox III]

Please explain why.

Because it assumes that any allocation of zero bytes is a failure, and,
presumably, won't be free'd.

 

[Barry Schwarz]

Hi All,

As per my understanding, malloc and calloc differs in the way they
allocate memory( malloc give a contigous block, But calloc may give
Non-contigous block as well).

Your understanding is incorrect. If they succeed, all three
allocation functions (malloc, calloc, and realloc) are guaranteed to
return a contiguous block of memory suitably aligned for any object
type. If they fail, all three are guaranteed to return NULL.

Now consider this program.

int main()
{
char *p;
p=(char *) calloc(10,sizeof(char));

*(p+2)='O';
*(p+8)='S';



return (0);
}
suppose calloc returns space in two blocks( 5 byte at address
starting at1000 and rest 5 bytes at 2000).
Now (p+2) is 1002.
(p+8) is 1008

But 1008 is not the part of space allocated to p.
I dont know my interpertation of non-contigous blocks is right or not.

This is really all the proof you need that your interpretation is
incorrect.



Remove del for email