malloc without stdlib.h

[Anton Dec]

Just curious about this...

malloc is defined in stdlib.h, right?

But if I write a program without #include<stdlib.hand use malloc, it
still works as expected.

Why is this? Is malloc automatically linked from somewhere else
magically?

[Default User]

Anton Dec wrote:

Just curious about this...

malloc is defined in stdlib.h, right?

But if I write a program without #include<stdlib.hand use malloc, it
still works as expected.

Why is this? Is malloc automatically linked from somewhere else
magically?

Show us the actual code.


Brian

[Richard Tobin]

In article <sl********************@nospam.com>,
Anton Dec <an******@mailinator.comwrote:

[I trust that isn't your real name.]

>malloc is defined in stdlib.h, right?

But if I write a program without #include<stdlib.hand use malloc, it
still works as expected.

Why is this? Is malloc automatically linked from somewhere else
magically?

Luck. Whether bad or good is a matter of opinion.

malloc() is not *defined* in stdlib.h, it's *declared* there. That
is, the types of its arguments and return values are specified. It's
definition is somewhere in the implementation, probably a library
that's linked with every program. Functions don't need to be declared
for linkers to find them in the library.

But if you don't declare it, things may go wrong. It will be assumed
to return int, when in fact it returns a void * pointer, so you may
get the wrong return value if ints and pointers are of different sizes
or are returned in different ways. The argument you pass to it will
be subject to the "default promotions", which means that for non-huge
values it will get passed as an int, when the argument should be of
type size_t. If int is smaller than size_t, malloc() may get the
wrong value.

It's worked for you because you are no doubt using a system where ints
and pointers are the same internally, and size_t is the same size as
int. There are an increasing number of systems where this isn't true
- commonly ones where pointers are size_t are 64 bits while int is 32.

So don't do it. You compiler should be giving you a warning; don't
ignore it.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Anton Dec said:

Just curious about this...

malloc is defined in stdlib.h, right?

But if I write a program without #include<stdlib.hand use malloc, it
still works as expected.

That is not only one of the possible consequences of undefined
behaviour, but also the most misleading.

Why is this? Is malloc automatically linked from somewhere else
magically?

Not magically, no. It's linked by the linker. But this is not a linker
issue - it's a compiler issue. You need to include the header because
the compiler needs information about malloc that is contained in that
header.

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

[Jack Klein]

On Wed, 6 Jun 2007 00:42:03 +0200 (CEST), Anton Dec
<an******@mailinator.comwrote in comp.lang.c:

Just curious about this...

malloc is defined in stdlib.h, right?

No, malloc() is prototyped in <stdlib.h>. I suppose it is possible
that there is at least one C implementation out there that actually
defines malloc() in <stdlib.h>, but I certainly don't expect to ever
find one.

But if I write a program without #include<stdlib.hand use malloc, it
still works as expected.

Really? What did you expect?

Why is this? Is malloc automatically linked from somewhere else
magically?

Yes, since malloc() is a function with external linkage, it is linked
from _somewhere_ . As for how magical that is, I'd have to examine
the source code of your linker.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Peter Nilsson]

Anton Dec <[e-mail]:

Just curious about this...

malloc is defined in stdlib.h, right?

No, it's declared.

But if I write a program without #include<stdlib.h>
and use malloc, it still works as expected.

Which may be by accident.

Why is this?

Possibly (bad) luck. C does not require function
prototypes to be in scope in order to use a function.
C90 does not even require a declaration since it will
assume a declaration in the case of undeclared named
functions. In the case of malloc, that assumed declaration
will be wrong because the assumption will be that it
returns an int.

You can use malloc correctly without including <stdlib.h>.
Either include a header that includes <stdlib.h>, or supply
a prototype somewhere in code...

void *malloc(size_t);

Note that size_t must be defined, and it can only be defined
properly by including one of the many standard headers that
defines it. So you may as well simply include <stdlib.h>.

Is malloc automatically linked from somewhere else
magically?

Linking is usually magic, even when programs are correct.

--
Peter

[CBFalconer]

Anton Dec wrote:

>
Just curious about this...

malloc is defined in stdlib.h, right?

But if I write a program without #include<stdlib.hand use
malloc, it still works as expected.

Why is this? Is malloc automatically linked from somewhere else
magically?

Because you are unlucky and malloc returns its value in the same
place as functions normally return integers.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Kenneth Brody]

Richard Tobin wrote:

>
In article <sl********************@nospam.com>,
Anton Dec <an******@mailinator.comwrote:

[I trust that isn't your real name.]

malloc is defined in stdlib.h, right?

But if I write a program without #include<stdlib.hand use malloc, it
still works as expected.

[...]

So don't do it. You compiler should be giving you a warning; don't
ignore it.

Well, it should give a warning unless he told the compiler to shut
up about the int-to-pointer conversion by casting malloc's return.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Richard Tobin]

In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:

>So don't do it. You compiler should be giving you a warning; don't
ignore it.

>Well, it should give a warning unless he told the compiler to shut
up about the int-to-pointer conversion by casting malloc's return.

So don't do that! In fact, unless you're compiling ancient programs
you should arrange for your compiler to warn about any unprototyped
functions.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Kenneth Brody]

Richard Tobin wrote:

>
In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:

[... OP's mention of malloc() without stdlib.h ...]

So don't do it. You compiler should be giving you a warning; don't
ignore it.

Well, it should give a warning unless he told the compiler to shut
up about the int-to-pointer conversion by casting malloc's return.

So don't do that!

Well, I thought that that goes without saying (for just such reasons),
but I guess not. :-)

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Army1987]

"Jack Klein" <ja*******@spamcop.netha scritto nel messaggio
news:pv********************************@4ax.com...

On Wed, 6 Jun 2007 00:42:03 +0200 (CEST), Anton Dec
<an******@mailinator.comwrote in comp.lang.c:

>Just curious about this...

malloc is defined in stdlib.h, right?

No, malloc() is prototyped in <stdlib.h>. I suppose it is possible
that there is at least one C implementation out there that actually
defines malloc() in <stdlib.h>, but I certainly don't expect to ever
find one.

The standard (7.1.4) guarantees that I can use malloc if I write
#include <stddef.h/* for size_t */
extern void *malloc(size_t size);

If malloc is defined in <stdlib.hthis is not possible.

[Eric Sosman]

Army1987 wrote On 06/08/07 09:40,:

"Jack Klein" <ja*******@spamcop.netha scritto nel messaggio
news:pv********************************@4ax.com...

>>On Wed, 6 Jun 2007 00:42:03 +0200 (CEST), Anton Dec
<an******@mailinator.comwrote in comp.lang.c:

>>>Just curious about this...

malloc is defined in stdlib.h, right?

No, malloc() is prototyped in <stdlib.h>. I suppose it is possible
that there is at least one C implementation out there that actually
defines malloc() in <stdlib.h>, but I certainly don't expect to ever
find one.

The standard (7.1.4) guarantees that I can use malloc if I write
#include <stddef.h/* for size_t */
extern void *malloc(size_t size);

Yes, any Standard library function must work if
declared as the Standard describes it, whether or not
the associated header is included. (For some functions,
correct declarations are impossible without the header,
but malloc() is not one of those.)

However, it's unwise to write free-hand declarations
like this. The function will work, but may not work
optimally if its declaration omits implementation-specific
magic that informs the compiler of some shortcuts or tricks
it can usefully take. getchar() and putchar() are classic
examples along these lines, but other functions may also
work better if declared magically:

void * _no_effect_on_errno_ malloc(size_t);

If malloc is defined in <stdlib.hthis is not possible.

I don't see why not. I've seen definitions -- yes,
definitions -- of toupper() et al. in <ctype.h>, so I see
no a priori reason to believe malloc() could not be done
the same way. It would be surprising, given malloc()'s
greater complexity, but not out of the question.

--
Er*********@sun.com

[Chris Dollin]

Eric Sosman wrote:

I don't see why not. I've seen definitions -- yes,
definitions -- of toupper() et al. in <ctype.h>, so I see
no a priori reason to believe malloc() could not be done
the same way. It would be surprising, given malloc()'s
greater complexity, but not out of the question.

The defined malloc might be a shim:

void* malloc( size_t n )
{ return _slightly_broken_system_malloc( n + 3 ); }

--
"We are on the brink of a new era, if only --" /The Beiderbeck Affair/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[CBFalconer]

Army1987 wrote:

>

.... snip ...

>
The standard (7.1.4) guarantees that I can use malloc if I write
#include <stddef.h/* for size_t */
extern void *malloc(size_t size);

If malloc is defined in <stdlib.hthis is not possible.

Yes it is. Besides which I see no such clause in N869. Use stdlib.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Army1987]

"Eric Sosman" <Er*********@sun.comha scritto nel messaggio
news:1181317044.599380@news1nwk...

Army1987 wrote On 06/08/07 09:40,:

>"Jack Klein" <ja*******@spamcop.netha scritto nel messaggio
news:pv********************************@4ax.com.. .

>>>On Wed, 6 Jun 2007 00:42:03 +0200 (CEST), Anton Dec
<an******@mailinator.comwrote in comp.lang.c:
Just curious about this...

malloc is defined in stdlib.h, right?

No, malloc() is prototyped in <stdlib.h>. I suppose it is possible
that there is at least one C implementation out there that actually
defines malloc() in <stdlib.h>, but I certainly don't expect to ever
find one.

The standard (7.1.4) guarantees that I can use malloc if I write
#include <stddef.h/* for size_t */
extern void *malloc(size_t size);

Yes, any Standard library function must work if
declared as the Standard describes it, whether or not
the associated header is included. (For some functions,
correct declarations are impossible without the header,
but malloc() is not one of those.)

However, it's unwise to write free-hand declarations
like this.

I've not saying that it is not a Bad Thing to do that, only that
the standard explicitly allows it.

[Keith Thompson]

"Army1987" <pl********@for.itwrites:

"Jack Klein" <ja*******@spamcop.netha scritto nel messaggio
news:pv********************************@4ax.com...

>On Wed, 6 Jun 2007 00:42:03 +0200 (CEST), Anton Dec
<an******@mailinator.comwrote in comp.lang.c:

>>Just curious about this...

malloc is defined in stdlib.h, right?

No, malloc() is prototyped in <stdlib.h>. I suppose it is possible
that there is at least one C implementation out there that actually
defines malloc() in <stdlib.h>, but I certainly don't expect to ever
find one.

The standard (7.1.4) guarantees that I can use malloc if I write
#include <stddef.h/* for size_t */
extern void *malloc(size_t size);

If malloc is defined in <stdlib.hthis is not possible.

This started, I think, because a previous poster misunderstood the
difference between a declaration and a definition.

I'm not sure about Army1987's argument, but if malloc were actually
*defined* in <stdlib.h>, then a program in which two separately
compiled translation units both have "#include <stdlib.h>" would have
two definitions of malloc. I believe that would render the
implementation non-conforming; a legal program would fail, probably
with a link-time error message.

--
Keith Thompson (The_Other_Keith) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Francine.Neary]

On Jun 8, 9:16 pm, Keith Thompson <[e-mail]:

"Army1987" <[e-mail]:

"Jack Klein" <[e-mail] scritto nel messaggio
news:pv********************************@4ax.com...

On Wed, 6 Jun 2007 00:42:03 +0200 (CEST), Anton Dec
<[e-mail] in comp.lang.c:

>Just curious about this...

>malloc is defined in stdlib.h, right?

No, malloc() is prototyped in <stdlib.h>. I suppose it is possible
that there is at least one C implementation out there that actually
defines malloc() in <stdlib.h>, but I certainly don't expect to ever
find one.

The standard (7.1.4) guarantees that I can use malloc if I write
#include <stddef.h/* for size_t */
extern void *malloc(size_t size);

If malloc is defined in <stdlib.hthis is not possible.

This started, I think, because a previous poster misunderstood the
difference between a declaration and a definition.

I'm not sure about Army1987's argument, but if malloc were actually
*defined* in <stdlib.h>, then a program in which two separately
compiled translation units both have "#include <stdlib.h>" would have
two definitions of malloc. I believe that would render the
implementation non-conforming; a legal program would fail, probably
with a link-time error message.

Isn't it required that including a header from the standard library
more than once is equivalent to including it once? In that case it
would be fine to define malloc in stdlib.h, as long as there was an
include-guard #define'd to ensure the definition was only included
once even if the header was #included more than once.

--
Keith Thompson (The_Other_Keith) [e-mail] <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Fr************@googlemail.com writes:

On Jun 8, 9:16 pm, Keith Thompson <[e-mail]:

[...]

>This started, I think, because a previous poster misunderstood the
difference between a declaration and a definition.

I'm not sure about Army1987's argument, but if malloc were actually
*defined* in <stdlib.h>, then a program in which two separately
compiled translation units both have "#include <stdlib.h>" would have
two definitions of malloc. I believe that would render the
implementation non-conforming; a legal program would fail, probably
with a link-time error message.

Isn't it required that including a header from the standard library
more than once is equivalent to including it once? In that case it
would be fine to define malloc in stdlib.h, as long as there was an
include-guard #define'd to ensure the definition was only included
once even if the header was #included more than once.

Including it multiple times is equivalent to including it once *within
a translation unit*. A program can be composed of multiple
translation units (separately compiled, joined together by the
linker).

--
Keith Thompson (The_Other_Keith) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Francine.Neary]

On Jun 8, 9:36 pm, Keith Thompson <[e-mail]:

[e-mail] writes:

On Jun 8, 9:16 pm, Keith Thompson <[e-mail]:

[...]

This started, I think, because a previous poster misunderstood the
difference between a declaration and a definition.

I'm not sure about Army1987's argument, but if malloc were actually
*defined* in <stdlib.h>, then a program in which two separately
compiled translation units both have "#include <stdlib.h>" would have
two definitions of malloc. I believe that would render the
implementation non-conforming; a legal program would fail, probably
with a link-time error message.

Isn't it required that including a header from the standard library
more than once is equivalent to including it once? In that case it
would be fine to define malloc in stdlib.h, as long as there was an
include-guard #define'd to ensure the definition was only included
once even if the header was #included more than once.

Including it multiple times is equivalent to including it once *within
a translation unit*. A program can be composed of multiple
translation units (separately compiled, joined together by the
linker).

Ah, I see what you mean. That does seem to imply that malloc can't be
defined in stdlib.h then.

--
Keith Thompson (The_Other_Keith) [e-mail] <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Fr************@googlemail.com writes:
[...]

Ah, I see what you mean. That does seem to imply that malloc can't be
defined in stdlib.h then.

It can, of course, be defined as a macro.

It's conceivable that there's some tricky way it could be defined as a
function, perhaps with some sort of compiler magic, but there wouldn't
be much point in doing so.

--
Keith Thompson (The_Other_Keith) 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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Joe Wright]

Fr************@googlemail.com wrote:

On Jun 8, 9:16 pm, Keith Thompson <[e-mail]:

>"Army1987" <[e-mail]:

>>"Jack Klein" <[e-mail] scritto nel messaggio
news:pv********************************@4ax.com. ..
On Wed, 6 Jun 2007 00:42:03 +0200 (CEST), Anton Dec
<[e-mail] in comp.lang.c:
Just curious about this...
malloc is defined in stdlib.h, right?
No, malloc() is prototyped in <stdlib.h>. I suppose it is possible
that there is at least one C implementation out there that actually
defines malloc() in <stdlib.h>, but I certainly don't expect to ever
find one.
The standard (7.1.4) guarantees that I can use malloc if I write
#include <stddef.h/* for size_t */
extern void *malloc(size_t size);
If malloc is defined in <stdlib.hthis is not possible.

This started, I think, because a previous poster misunderstood the
difference between a declaration and a definition.

I'm not sure about Army1987's argument, but if malloc were actually
*defined* in <stdlib.h>, then a program in which two separately
compiled translation units both have "#include <stdlib.h>" would have
two definitions of malloc. I believe that would render the
implementation non-conforming; a legal program would fail, probably
with a link-time error message.

Isn't it required that including a header from the standard library
more than once is equivalent to including it once? In that case it
would be fine to define malloc in stdlib.h, as long as there was an
include-guard #define'd to ensure the definition was only included
once even if the header was #included more than once.

I wonder if you are missing the difference between 'declare' and
'define' in terms of headers. A header provides the compiler with
information about things. These bits of information are 'declarations'
and do not take up memory. In stdlib.h we find something like..

void *malloc(size_t);

This is a declaration and in fact a prototype. It is not a definition.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Francine.Neary]

On Jun 8, 11:58 pm, Joe Wright <[e-mail]:

I wonder if you are missing the difference between 'declare' and
'define' in terms of headers. A header provides the compiler with
information about things. These bits of information are 'declarations'
and do not take up memory. In stdlib.h we find something like..

void *malloc(size_t);

This is a declaration and in fact a prototype. It is not a definition.

That's right. But the whole point of the preceding discussion was:
could an implementation put a definition (*not* just a declaration) of
malloc in stdlib.h?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---