calloc()

[Michael McGarry]

Hi,

What would cause calloc() to return a NULL pointer?

Is the system simply out of memory?

Regards,

Michael

 

[Default User]

Hi,

What would cause calloc() to return a NULL pointer?

Is the system simply out of memory?

It's unlikely to be out. However, it may not have a piece available to
your program that is large enough to fill the request.




Brian

 

[Michael McGarry]

Is there anything I can do to fix that?

I guess if there is not contiguous memory of the size I need I am out
of luck?

Thanks for any help,

Michael

 

[Ian Collins]

Is there anything I can do to fix that?

I guess if there is not contiguous memory of the size I need I am out
of luck?

Thanks for any help,

Please don't top post.

Assuming you implementation has errno, you should test its value after
the failing call to determine the cause of the failure.

If there isn't contiguous memory of the size you need, you are out of
luck and should consider a different design. As an alternative, try
allocating the bigger memory blocks earlier.

 

[Joe Wright]

Hi,

What would cause calloc() to return a NULL pointer?

Is the system simply out of memory?

Regards,

Michael

Something like that. Given rational arguments, malloc, calloc and
realloc seldom error out. But you can stress them. For example size_t is
an unsigned 32-bit type on my system. calloc multiplies its two size_t
arguments to come up with size. If these two are not chosen with some
sanity, calloc will barf because I don't have anything near 2^64 bytes
of memory to address.

 

[Keith Thompson]

Please don't top post.

Assuming you implementation has errno, you should test its value after
the failing call to determine the cause of the failure.

His implementation certainly has error if it's a conforming hosted
implementation. But the standard doesn't say that malloc() sets errno
on a failure. And even if it does, it's not likely to distinguish
between different forms of "not enough memory".

If there isn't contiguous memory of the size you need, you are out of
luck and should consider a different design. As an alternative, try
allocating the bigger memory blocks earlier.

Some systems impose limits on how much memory a given program (or
process, or user, or whatever) can allocate. You may or may not be
able to increase that limit; the details are system-specific.

It's also possible that you haven't run out of available memory,
rather than you've done something to mess up the system's internal
data structures.

Incidentally, calloc() isn't necessarily more useful than the simpler
malloc(); calloc() initializes the allocated memory to all-bits-zero,
but that's not necessarily as useful as you might think. In
particular, neither floating-point 0.0 nor null pointers are
guaranteed to be represented as all-bits-zero.

 

[Default User]

Don't top-post, text rearranged.

Is there anything I can do to fix that?

I guess if there is not contiguous memory of the size I need I am out
of luck?

Pretty much. However, it's not a common occurrence for modern systems.
Is this theoretical, or an actual problem you've encountered?




Brian

 

[Ian Collins]

His implementation certainly has error if it's a conforming hosted
implementation.

I was careful not to make that assumption.

But the standard doesn't say that malloc() sets errno
on a failure. And even if it does, it's not likely to distinguish
between different forms of "not enough memory".

True, but all it takes is a quick read of the platform's documentation
to see if it does. Solaris and I think Linux makes the distinction.

Some systems impose limits on how much memory a given program (or
process, or user, or whatever) can allocate. You may or may not be
able to increase that limit; the details are system-specific.

If you know your allocation is within these bounds, there's a pretty
good chance you have run into a fragmentation issue, so my suggestion is
still worth investigation.

 

[Flash Gordon]

Please don't top post.

Assuming you implementation has errno,

If it is a hosted C implementation then it has errno.

> you should test its value after
the failing call to determine the cause of the failure.

The standard does not require that errno be set. The Unix98 standard
requires that it be set to ENOMEM on failure if the linux documentation
is accurate, but if it is always set to ENOMEM on failure that gives you
no additional information.

In other words, checking errno in this instance is pointless on at least
one implementation and quite likely pointless on a number of others.

If there isn't contiguous memory of the size you need, you are out of
luck and should consider a different design. As an alternative, try
allocating the bigger memory blocks earlier.

This is better advice. I would also suggest checking for memory leaks
and making sure you are passing sensible numbers to calloc.

 

[Richard]

I was careful not to make that assumption.

True, but all it takes is a quick read of the platform's documentation
to see if it does. Solaris and I think Linux makes the distinction.

Would Linux, in default, ever return NULL? The default is to return
pointers to memory that is not even available : optimistic
strategy. Yuck I might, time allowing, knock up a program to fragment
up the memory and then try a huge alloc.

Q: does the swapfile come on "seamlessly" on most platforms here? In
which case would we ever see malloc failing assuming enough swap? How
does that work (yes I know OT)? Even if the swap is fragmented is the
memory block contiguous?

 

[Richard Heathfield]

Richard said:

Would Linux, in default, ever return NULL?

Yes. Try a GREAT BIG allocation.

 

[Keith Thompson]

His implementation certainly has error if it's a conforming hosted
implementation. But the standard doesn't say that malloc() sets errno
on a failure. And even if it does, it's not likely to distinguish
between different forms of "not enough memory".

That was a particularly misleading typo; I meant that his
implementation certainly has *errno* if it's a conforming hosted
implementation.

 

[Al Balmer]

Q: does the swapfile come on "seamlessly" on most platforms here?

In HP-UX, yes.

In
which case would we ever see malloc failing assuming enough swap?

Yes, if your program is ambitious enough.

How
does that work (yes I know OT)?

There is a per-process limit. For the (rather old, HP-UX 11.0) system
I'm logged into now, it's 67 MB data segment, 83 MB stack, and 67 MB
text (program). That's configurable, and the defaults are larger on
newer systems.

Even if the swap is fragmented is the
memory block contiguous?

As far as a C program is concerned, yes.

 

[Al Balmer]

If it is a hosted C implementation then it has errno.


The standard does not require that errno be set. The Unix98 standard
requires that it be set to ENOMEM on failure if the linux documentation
is accurate, but if it is always set to ENOMEM on failure that gives you
no additional information.

On HP-UX, errno is set to EINVAL if memory has been detectably
corrupted. If there's insufficient memory, there's no clue as to the
reason. Of course, there's nothing to say that logically contiguous
memory must be physically contiguous.

 

[Michael McGarry]

It turns out I was just eating up way too much memory.

I am trying to figure out how that happened.

Thanks for all the advice,

Michael

 

[Ian Collins]

If it is a hosted C implementation then it has errno.




The standard does not require that errno be set. The Unix98 standard
requires that it be set to ENOMEM on failure if the linux documentation
is accurate, but if it is always set to ENOMEM on failure that gives you
no additional information.

In other words, checking errno in this instance is pointless on at least
one implementation and quite likely pointless on a number of others.

Perhaps Solaris is unique in making the distinction by setting errno to
ENOMEM if the request is bigger than the system limits and EAGAIN if
there isn't enough memory available at the instant the request was made.

Either way, it's still worth checking your implementation's documentation.

 

[Flash Gordon]

Perhaps Solaris is unique in making the distinction by setting errno to
ENOMEM if the request is bigger than the system limits and EAGAIN if
there isn't enough memory available at the instant the request was made.

Interesting that there are some systems that set errno to different values.

Either way, it's still worth checking your implementation's documentation.

That I'll agree with. When try to debug a nasty problem it is always
worth checking the implementations documentation to see what tools are
available. Whether that be errno being set to useful values when it is
not required or debugging versions of malloc or anything else.

 

[Richard]

Interesting that there are some systems that set errno to different values.


That I'll agree with. When try to debug a nasty problem it is always
worth checking the implementations documentation to see what tools are
available. Whether that be errno being set to useful values when it is
not required or debugging versions of malloc or anything else.

In the greater majority of C development that requires use of such
functions I'd go even further and say its mandatory to check the
implementation specific errno settings. Not everything can be fully
portable : in which case make it fully platform safe - with the usual
documented caveats.

 

[Default User]

It turns out I was just eating up way too much memory.

You were asked previously in this thread not to top-post. Why do you
continue to abuse the newsgroup?




Brian

 

[Herbert Rosenau]

Hi,

What would cause calloc() to return a NULL pointer?

calloc/malloc is unable to give you continous memory in the requested
size.

Is the system simply out of memory?

Maybe, maybe not.

The system may have some TB available but the process your calloc is
in has eaten all memory the system will give it.

By that: calloc is alöways useless except you are allocating real char
arrays.

calloc fills the memory block with binary 0. But there is no guaratee
that ponters floatingpoint variables or even structs are valid when
set to binary 0 chars. Character arrays are the only guaranteed to be
ready for usage when filled with binary 0. Pointers are not,
floatingpoint variables are not and even structs are not. On some
environments it may work, on others it will crash depending on the
underlying hardware.

So use malloc instead and initialise the variables with theyr typed
form of 0, e.g 0.0, or 0. calloc has no idea which kind of 0 the
variable needs, the compiler does, so it will convert a simple 0 to
its real type (0.0, (void*)0,...) for you.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!