calloc()

[Michael McGarry]

Hi,

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

Is the system simply out of memory?

Regards,

Michael

[Richard Heathfield]

Richard said:

<snip>

Would Linux, in default, ever return NULL?

Yes. Try a GREAT BIG allocation.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

Keith Thompson <ks***@mib.orgw rites:

Ian Collins <ia******@hotma il.comwrites:

[...]

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

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

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Al Balmer]

On Tue, 08 Aug 2006 00:37:17 +0200, Richard <rg****@gmail.c omwrote:

>
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
Sun City, AZ

[Al Balmer]

On Mon, 07 Aug 2006 23:21:11 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwro te:

>Ian Collins wrote:

>Michael McGarry wrote:

>>Default User wrote:

Michael McGarry wrote:
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.

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,

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.

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.

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

--
Al Balmer
Sun City, AZ

[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

Al Balmer wrote:

On Mon, 07 Aug 2006 23:21:11 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwro te:

Ian Collins wrote:

Michael McGarry wrote:
Default User wrote:

Michael McGarry wrote:
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.

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,

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.

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.

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.

--
Al Balmer
Sun City, AZ

[Ian Collins]

Flash Gordon wrote:

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

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.

--
Ian Collins.

[Flash Gordon]

Ian Collins wrote:

Flash Gordon wrote:

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

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.
--
Flash Gordon
Still sigless on this computer.

[Richard]

Flash Gordon <sp**@flash-gordon.me.ukwri tes:

Ian Collins wrote:

>Flash Gordon wrote:

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

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.

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]

Michael McGarry wrote:

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]

On Mon, 7 Aug 2006 21:26:41 UTC, "Michael McGarry"
<mi************ *@gmail.comwrot e:

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!