Where does fatal() come from?

[grocery_stocker]

Given the following snippet of code:
(taken from
http://www.gnu.org/software/libc/manual/html_node/Malloc-Examples.html)

void *
xmalloc (size_t size)
{
register void *value = malloc (size);
if (value == 0)
fatal ("virtual memory exhausted");
return value;
}


What header file is fatal() located in? Also, why not just use
something like printf() or perror()?

 

[Keith Thompson]

Given the following snippet of code:
(taken from
http://www.gnu.org/software/libc/manual/html_node/Malloc-Examples.html)

void *
xmalloc (size_t size)
{
register void *value = malloc (size);
if (value == 0)
fatal ("virtual memory exhausted");
return value;
}


What header file is fatal() located in? Also, why not just use
something like printf() or perror()?

There is nothing called fatal() in any of the C standard headers. It
may be part of libc. Presumably it does something more than printing
an error message to stdout or stderr (my guess is that it then aborts
the program).

 

[sathyashrayan]

Given the following snippet of code:
(taken from
http://www.gnu.org/software/libc/manual/html_node/Malloc-Examples.html)

void *
xmalloc (size_t size)
{
register void *value = malloc (size);
if (value == 0)
fatal ("virtual memory exhausted");
return value;
}


What header file is fatal() located in? Also, why not just use
something like printf() or perror()?

Example
int *a = malloc(size)
if(a == NULL)
error
is same as the above xmalloc.The above xmalloc normally called as a malloc wrapper function.

Xmalloc some time is used to contain the malloc argument is zero conditions check. If we pass zero to a malloc
argument it's return value is null.(I am correct).But the following code works as expected:

#include<stdio.h>
#include<stdlib.h>

int main(void)
{
char *a;
a = malloc(0);
if(a==NULL)
printf("malloc is NULL\n");
else
{
a = "comp.lang.c";
printf("%s",a);
}
return 0;
}

Is the above UB?

--
"combination is the heart of chess"

A.Alekhine

Mail to:
sathyashrayan AT gmail DOT com

 

[CBFalconer]

.... snip ...

#include<stdio.h>
#include<stdlib.h>

int main(void)
{
char *a;
a = malloc(0);
if(a==NULL)
printf("malloc is NULL\n");
else
{
a = "comp.lang.c";
printf("%s",a);
}
return 0;
}

Is the above UB?

Yes, assuming you meant to write *a = ".." and mistyped a. Even if
malloc(0) returns non-NULL, the space allocated has no room, so you
can't store anything there. If you didn't mean *a you have just
discarded a malloced pointer and had a memory leak.

 

[Jirka Klaue]

sathyashrayan:

No, but the output depends on implementation-defined behaviour.
And your second printf needs a '\n'.

Yes, assuming you meant to write *a = ".." and mistyped a. Even if
malloc(0) returns non-NULL, the space allocated has no room, so you
can't store anything there.

Not even if strcpy would be used. ;-)

If you didn't mean *a you have just
discarded a malloced pointer and had a memory leak.

Are you sure that failing to free a malloc(0) call leads to a memory leak?

Jirka

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


Are you sure that failing to free a malloc(0) call leads to a
memory leak?

Yes, I know of such systems. There is always a chance it may not,
on a particular system. From N869:

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 freed or
reallocated). 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 implementation-defined: 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. The value of a pointer
that refers to freed space is indeterminate.

 

[Lawrence Kirby]

On Tue, 14 Jun 2005 16:01:00 +0200, Jirka Klaue wrote:

....

Are you sure that failing to free a malloc(0) call leads to a memory leak?

If malloc() returned non-null is very likely will. In addition to the
memory available for the program to use, of which there may be none, a
successful malloc() typically creates internal housekeeping information
which takes up space. Not freeing this up appropriately constitutes a
memory leak.

Lawrence

 

[Keith Thompson]

Yes, assuming you meant to write *a = ".." and mistyped a. Even if
malloc(0) returns non-NULL, the space allocated has no room, so you
can't store anything there. If you didn't mean *a you have just
discarded a malloced pointer and had a memory leak.

I'm not sure why you're assuming he meant *a; the suggested *a = ".."
is illegal, but the program as written is ok.

If the code above were executed somewhere other than just before
leaving main(), it would be a (small) memory leak. But once the
program terminates (and returns a status to the environment), the
standard becomes silent. It's probably good style to release all
allocated memory, even if the program is about to terminate (after all
the code could later be moved into a function that might be called
repeatedly). But on any sensible system, allocated memory should be
returned to the system when the program terminates, whether it's been
free()d or not.

To put it another way, the standard doesn't guarantee that malloc()ed
memory that hasn't been free()d is returned to the operating system --
but neither does it guarantee that malloc()ed memory that *has* been
free()d is returned to the operating system. Failing to reclaim
un-free()d memory and failing to reclaim free()d memory are both bugs
(but not violations of the C standard); neither bug, IMHO, is much
worse than the other.

(Possibly the tradeoffs are different in embedded systems.)