void *malloc(size_t num_bytes);

[Alawna]

Hi,
i was reading a chapter about c pointers in "c++builder complete
reference" and it is said there that malloc returns a pointer to the
start of the memory allocated but i see the prototype of it saying void
*malloc(----);
does not void mean that the function does not return anything?
thanks

[Mark F. Haigh]

Alawna wrote:

Hi,
i was reading a chapter about c pointers in "c++builder complete
reference" and it is said there that malloc returns a pointer to the
start of the memory allocated but i see the prototype of it saying void
*malloc(----);
does not void mean that the function does not return anything?
thanks

A "void *" means roughly "a pointer to something". Thus, the malloc
function returns a pointer to a memory location where you can store
something.

Review your section on pointers. Don't confuse "void" with "void *".

Mark F. Haigh
mf*****@sbcglobal.net

[Alawna]

thanks

[Alawna]

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?

[forayer]

Alawna wrote:

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?

not exactly.

u see, a malloc call is as below:
<pointer var> = (pointer type cast)malloc( num bytes needed );

now, if u want to dynamically allocate an int, u wud pass da size of an
int to malloc as:
malloc( sizeof(int) );
this will allocate 2 bytes (assuming int is 2 bytes long) in some loc
in memory, n return the _address_ to that loc.
to use that allocated mem u need sumthin to ref it. so u use an 'int'
ptr. so if u hav an int *p, then
p = (int *)malloc( sizeof(int) );
will make p point to the allocated addr.

in case of allocation failure, malloc will return NULL, so chk 4 it b4
usin p, or b prepared 4 sum nasty seg faults!

cheers,
forayer

[Martin Ambuhl]

Alawna wrote:

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?

No, it would be (if the integer type happens to be int)
int malloc( /* whatever */);
But we know that malloc does not return an int.

[Emmanuel Delahaye]

Alawna wrote on 19/06/05 :

Hi,
i was reading a chapter about c pointers in "c++builder complete
reference" and it is said there that malloc returns a pointer to the
start of the memory allocated but i see the prototype of it saying void
*malloc(----);
does not void mean that the function does not return anything?
thanks

Nope. You are mixing 'void' (returns nothing) and 'void*' (returns an
address of unspecified type).

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair

[Emmanuel Delahaye]

Alawna wrote on 19/06/05 :

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?

No. If a function must return an int, its return type will be int

int f (void);

Stay simple.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

[Alawna]

thank you guys.
got it now. need more time to get used to c syntax. coming from pascal.

Emmanuel Delahaye wrote:

Alawna wrote on 19/06/05 :

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?

No. If a function must return an int, its return type will be int

int f (void);

Stay simple.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

[Tim Rentsch]

"Mark F. Haigh" <mf*****@sbcglobal.net> writes:

[snip]

A "void *" means roughly "a pointer to something".

So "pointer to nothing" means roughly "a pointer to something"?!??

That's why we like C!

:)

[forayer]

Tim Rentsch wrote:

"Mark F. Haigh" <mf*****@sbcglobal.net> writes:

[snip]

A "void *" means roughly "a pointer to something".

So "pointer to nothing" means roughly "a pointer to something"?!??

no, 'void *' means a pointer to any kind of thing! but it definitely
points to something, though this "something" can even be NULL!!!

Now, that's why we luv C
;-D

[Flash Gordon]

forayer wrote:

Alawna wrote:

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?
not exactly.

u see, a malloc call is as below:

Please don't use abbreviations like u for you, it makes it unnecessarily
hard to read your posts, especially for those whose native language is
not English.
<pointer var> = (pointer type cast)malloc( num bytes needed );
The cast is *not* required.
now, if u want to dynamically allocate an int, u wud pass da size of an
int to malloc as:
malloc( sizeof(int) );
A far better method is
ptr = malloc( N * sizeof *ptr );
Then you don't get the type wrong (which typically happens when
allocating space for more complex items such as pointers to pointers)
and you don't have to change the line if the type of ptr is changed.
this will allocate 2 bytes (assuming int is 2 bytes long) in some loc
in memory, n return the _address_ to that loc.
to use that allocated mem u need sumthin to ref it. so u use an 'int'
ptr. so if u hav an int *p, then
p = (int *)malloc( sizeof(int) );
will make p point to the allocated addr.
As stated above, the cast is not required. If the compiler complains
without the cast then there is something else wrong, such as using a C++
compiler or failing to include stdlib.h
in case of allocation failure, malloc will return NULL, so chk 4 it b4
usin p, or b prepared 4 sum nasty seg faults!

That sentence took me twice as long to read as it should have because of
the stupid abbreviations.

seg faults are specific to some OSs, not required by the standard. Far
worse than getting seg faults can happen, such as it appearing to work
until you show the program to you girlfriend to demonstrate how clever
you are and instead of doing what you expected it prints out a love poem
addressed to her best friend.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Joe Wright]

forayer wrote:

Tim Rentsch wrote:

"Mark F. Haigh" <mf*****@sbcglobal.net> writes:

[snip]

A "void *" means roughly "a pointer to something".

So "pointer to nothing" means roughly "a pointer to something"?!??

no, 'void *' means a pointer to any kind of thing! but it definitely
points to something, though this "something" can even be NULL!!!

Now, that's why we luv C
;-D

No. NULL is a value, not a type. NULL valued pointers point to nothing
regardless the type of the pointer.

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

[forayer]

Joe Wright wrote:

No. NULL is a value, not a type. NULL valued pointers point to nothing
regardless the type of the pointer.

all i meant to say was that a 'void *' can _sometimes_ be a pointer to
nothing, but not always as Tim said it to be. :-)

cheers,
forayer

[Tim Rentsch]

"forayer" <th********@hotmail.com> writes:

Tim Rentsch wrote:

"Mark F. Haigh" <mf*****@sbcglobal.net> writes:

> [snip]

A "void *" means roughly "a pointer to something".

So "pointer to nothing" means roughly "a pointer to something"?!??

no, 'void *' means a pointer to any kind of thing! but it definitely
points to something, though this "something" can even be NULL!!!

A NULL pointer isn't a pointer to anything.

A 'void *' is a pointer to nothing - just dereference it
to get that void value. :)

Speaking of which, why isn't

void
foo(){
void *p = ...whatever...;

return *p;
}

allowed?

It's all just humor, don't take it too seriously....

[forayer]

Flash Gordon wrote:

Please don't use abbreviations like u for you, it makes it unnecessarily
hard to read your posts, especially for those whose native language is
not English.
mate, i apologized once, and apologized to everyone in that message.
now what do you guys want me to do? say sorry for each and every post i
made in which i have used the abbreviations??? come on...

<pointer var> = (pointer type cast)malloc( num bytes needed );

The cast is *not* required.

Yes, it is not required is C, but C++ does require it. besides the cast
cant harm anyone, unless its being incorrectly cast!

now, if u want to dynamically allocate an int, u wud pass da size of an
int to malloc as:
malloc( sizeof(int) );
A far better method is
ptr = malloc( N * sizeof *ptr );
Then you don't get the type wrong (which typically happens when
allocating space for more complex items such as pointers to pointers)
and you don't have to change the line if the type of ptr is changed.

That does make some sense, but what if ptr is of type 'void *'?

in case of allocation failure, malloc will return NULL, so chk 4 it b4
usin p, or b prepared 4 sum nasty seg faults!

That sentence took me twice as long to read as it should have because of
the stupid abbreviations.

well, i will just expand that sentence so that someone else reading it
doesnt have to go through as much trouble as you did (no offence
intented):
"in case of an allocation failure, malloc will return 'NULL', so check
for it before using 'p', or be prepared for some nasty segmentation
faults!"
seg faults are specific to some OSs, not required by the standard. Far
worse than getting seg faults can happen, such as it appearing to work
until you show the program to you girlfriend to demonstrate how clever
you are and instead of doing what you expected it prints out a love poem
addressed to her best friend.

I agree. seg faults are specific to some OSs. But if p=NULL, and then
you do a p->func(), no matter what the OS, it is a runtime error, dont
you think?

cheers,
forayer

[forayer]

Tim Rentsch wrote:

It's all just humor, don't take it too seriously....
Hey, i meant it in good health too. so, dont take the rest seriously,
okay?
A NULL pointer isn't a pointer to anything.

A 'void *' is a pointer to nothing - just dereference it
to get that void value. :)
Huh? a pointer that doesnt point to anything, and a pointer that points
to nothing are not the same, eh? hmmm...
Speaking of which, why isn't

void
foo(){
void *p = ...whatever...;

return *p;
}

allowed?

maybe because it doesnt make any sense! how can you make use of a void
return anyway? ;-)

cheers,
forayer

[Chris Torek]

>Flash Gordon wrote:

The cast [on malloc's return value] is *not* required.
In article <11**********************@z14g2000cwz.googlegroups .com>
forayer <th********@hotmail.com> wrote:

Yes, it is not required is C, but C++ does require it. besides the cast
cant harm anyone, unless its being incorrectly cast!
If you are writing C++ code, you should not be using malloc() at all
(you should be using container classes and/or "new"). It is generally
unwise to compile code intended as C using a C++ compiler, as the
semantics may change unexpectedly:

#include <stdio.h>
struct S { char a[1]; };
int main(void) {
struct T { struct S { char a[1000]; } a; };
printf("sizeof(struct S) = %lu\n", (unsigned long)sizeof(struct S));
return 0;
}

(Exercise: what is the most likely output of the above, as both
C and C++? Why is it different?)

In any case, in my experience here in comp.lang.c (since it was
net.lang.c back in 1983 or so), I find that code that contains a
cast usually does so *because* it is being "incorrectly cast".
(In particular, the use of a cast is a strong hint that the programmer
has failed to "#include <stdlib.h>". This was not true in 1983,
mind you; but at that time, <stdlib.h> did not exist either. Nor
did C++, for that matter. :-) )
A far better method is
ptr = malloc( N * sizeof *ptr );

(This is my favorite version as well.)
That does make some sense, but what if ptr is of type 'void *'?
Yes, as Lawrence Kirby noted, in that case, the call cannot follow
the pattern. Of course, if "ptr" is declared as "void *", the
appropriate size for the malloc() call has to be supplied separately:

/* like malloc, but print error message and exit on failure */
void *emalloc(size_t size) {
void *p = malloc(size);
if (p == NULL) {
panic("out of memory");
/* NOTREACHED */
}
return p;
}

There are cases where I drop the "N *" part, when I know I want
one object:

struct S *p;
...
p = malloc(sizeof *p);

Of course, 1 * x == x, for all integral x, in C.

There is another case for which I drop the "sizeof *ptr", when
"ptr" points to (plain) char:

char *dupstr(char *orig) {
char *s;
size_t len = strlen(orig) + 1; /* +1 to account for '\0' */

s = malloc(len);
if (s != NULL) /* or maybe use emalloc() */
memcpy(s, orig, len);
return s;
}

because sizeof(char) == 1 (by definition). I feel reasonably safe
in this case, because if someone decides to change "char" to some
internal "wider character" type, the strlen() call will also become
incorrect, and the dupstr() function as a whole will need rework,
not just the type of "s".
I agree. seg faults are specific to some OSs. But if p=NULL, and then
you do a p->func(), no matter what the OS, it is a runtime error, dont
you think?

This depends on how you define "runtime error". There are machines
on which this turns out to be a recursive call to main(). (In C,
main() may be called recursively, unlike C++. This is another
reason not to attempt to compile C code with a C++ compiler. :-) )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[forayer]

Chris Torek wrote:

If you are writing C++ code, you should not be using malloc() at all
(you should be using container classes and/or "new"). It is generally
unwise to compile code intended as C using a C++ compiler, as the
semantics may change unexpectedly:

#include <stdio.h>
struct S { char a[1]; };
int main(void) {
struct T { struct S { char a[1000]; } a; };
printf("sizeof(struct S) = %lu\n", (unsigned long)sizeof(struct S));
return 0;
}

(Exercise: what is the most likely output of the above, as both
C and C++? Why is it different?)

1000 using C, and 1 using C++. My money is on scope-resolution
differences between the languages. Please correct me if I am wrong.
In any case, in my experience here in comp.lang.c (since it was
net.lang.c back in 1983 or so), I find that code that contains a
cast usually does so *because* it is being "incorrectly cast".
(In particular, the use of a cast is a strong hint that the programmer
has failed to "#include <stdlib.h>". This was not true in 1983,
mind you; but at that time, <stdlib.h> did not exist either. Nor
did C++, for that matter. :-) )

Neither did I, LOL ;-)
This depends on how you define "runtime error". There are machines
on which this turns out to be a recursive call to main().

I really didn't know that, thank you. :-)

regards,
forayer

[Emmanuel Delahaye]

forayer wrote on 19/06/05 :

Yes, it is not required is C, but C++ does require it.
So what ? Tell me you are not compiling a C source with a C++
compiler...

ptr = malloc( N * sizeof *ptr );

That does make some sense, but what if ptr is of type 'void *'?

It means that the type is probably wrong.
I agree. seg faults are specific to some OSs. But if p=NULL, and then
you do a p->func(), no matter what the OS, it is a runtime error, dont
you think?

Who knows. The behaviour is undefined...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

[CBFalconer]

forayer wrote:

Flash Gordon wrote:

Please don't use abbreviations like u for you, it makes it
unnecessarily hard to read your posts, especially for those whose
native language is not English.

mate, i apologized once, and apologized to everyone in that message.
now what do you guys want me to do? say sorry for each and every
post i made in which i have used the abbreviations??? come on...

Pointing up the fact that various readers don't see the same
articles or sequence that you or other readers see. Apologies are
not needed one by one, just don't do it in future. And please also
use an uppercase I for the first person singular, it is also much
easier to read.

Chris Torek has covered the other points in his usual admirable
fashion.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[CBFalconer]

forayer wrote:

Joe Wright wrote:

No. NULL is a value, not a type. NULL valued pointers point to
nothing regardless the type of the pointer.

all i meant to say was that a 'void *' can _sometimes_ be a
pointer to nothing, but not always as Tim said it to be. :-)

You will very rarely declare anything of type void* (apart from
function parameters and possibly return type). In fact I can't
think of any such need for now.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[forayer]

CBFalconer wrote:

Pointing up the fact that various readers don't see the same
articles or sequence that you or other readers see. Apologies are
not needed one by one, just don't do it in future. And please also
use an uppercase I for the first person singular, it is also much
easier to read.

I will keep that in mind too. Please ignore the posts I just made with
the lowercase 'i'. I did it before I read your post. Sorry.

Cheers,
forayer

[john_bode]

Alawna wrote:

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?

No. malloc() returns pointer to void -- period. It does not return an
integer type. The resulting pointer value can be *cast* to an integer
value, although whether that resulting integer is useful or not is an
open issue.

[Chris Dollin]

Alawna wrote:

so let us suppose that malloc returns an integer then its prototype
would be int void *malloc(-----); . is this accurate?

It's syntactically illegal; accuracy isn't applicable.

--
Chris "electric hedgehog" Dollin
It's called *extreme* programming, not *stupid* programming.

[Lawrence Kirby]

On Sun, 19 Jun 2005 10:26:10 -0700, Tim Rentsch wrote:

"forayer" <th********@hotmail.com> writes:

Tim Rentsch wrote:

> "Mark F. Haigh" <mf*****@sbcglobal.net> writes:
>
> > > [snip]
> >
> > A "void *" means roughly "a pointer to something".
>
> So "pointer to nothing" means roughly "a pointer to something"?!??
no, 'void *' means a pointer to any kind of thing! but it definitely
points to something, though this "something" can even be NULL!!!

A NULL pointer isn't a pointer to anything.

Yes, a null pointer is a pointer that doesn't point.
A 'void *' is a pointer to nothing - just dereference it
to get that void value. :)
A void * pointer can point at an object, you just don't know what type of
object it is pointing at. Whether a non-null void * pointer value is valid
or not depends on whether it is pointing at an object or one place past
the end of an array.

Speaking of which, why isn't

void
foo(){
void *p = ...whatever...;

return *p;
}

allowed?

It's all just humor, don't take it too seriously....

Sense prevailed.

Lawrence

[Keith Thompson]

"forayer" <th********@hotmail.com> writes:

Flash Gordon wrote:

Please don't use abbreviations like u for you, it makes it unnecessarily
hard to read your posts, especially for those whose native language is
not English.

mate, i apologized once, and apologized to everyone in that message.
now what do you guys want me to do? say sorry for each and every post i
made in which i have used the abbreviations??? come on...

Usenet is an asynchronous medium. Articles do not necessarily appear
in the order in which they were posted (assuming they appear at all),
and individuals may read articles in any arbitrary order. (That's why
it's so important to quote properly (a general comment, not meant to
imply that you haven't.))

I'll take your word for it that you've apologized elsewhere in this
thread, but I haven't seen that article yet, and I presume Flash
Gordon hadn't seen it either. (It's probably on my server, I just
haven't gotten to it yet.)

You should see what happens in comp.lang.c.moderated. Articles don't
appear until they've been cleared by the moderator. A single question
can be followed days or weeks later by a dozen similar responses, all
written by people who've seen only the original question.

[...]

seg faults are specific to some OSs, not required by the standard. Far
worse than getting seg faults can happen, such as it appearing to work
until you show the program to you girlfriend to demonstrate how clever
you are and instead of doing what you expected it prints out a love poem
addressed to her best friend.

I agree. seg faults are specific to some OSs. But if p=NULL, and then
you do a p->func(), no matter what the OS, it is a runtime error, dont
you think?

Any attempt to dereference a null pointer invokes undefined behavior.
There is no requirement for the implementation to detect the error.
In many cases, undefined behavior results in the program behaving just
as you expect it to, failing only at a critical moment during a
demonstration for an important customer. The old joke around here is
that one of the allowed consequences of undefined behavior is that it
causes demons to fly out of your nose.

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

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

forayer wrote:

Flash Gordon wrote:

Please don't use abbreviations like u for you, it makes it
unnecessarily hard to read your posts, especially for those whose
native language is not English.

mate, i apologized once, and apologized to everyone in that message.
now what do you guys want me to do? say sorry for each and every
post i made in which i have used the abbreviations??? come on...

Pointing up the fact that various readers don't see the same
articles or sequence that you or other readers see. Apologies are
not needed one by one, just don't do it in future.

The fact that I made the same point was just my clever way of
demonstrating the phenomenon, not an indication that I was too lazy to
read the entire thread before posting redundant followups. Yeah,
that's it.

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

[forayer]

Keith Thompson wrote:

Usenet is an asynchronous medium. Articles do not necessarily appear
in the order in which they were posted (assuming they appear at all),
and individuals may read articles in any arbitrary order. (That's why
it's so important to quote properly (a general comment, not meant to
imply that you haven't.))

I'll take your word for it that you've apologized elsewhere in this
thread, but I haven't seen that article yet, and I presume Flash
Gordon hadn't seen it either. (It's probably on my server, I just
haven't gotten to it yet.)
That explains a lot. My apology letter is in another thread, and you
participated in it only recently (Flash Gordon has not yet participated
in it). Anyway, I'm sorry you guys.
Any attempt to dereference a null pointer invokes undefined behavior.
There is no requirement for the implementation to detect the error.
In many cases, undefined behavior results in the program behaving just
as you expect it to, failing only at a critical moment during a
demonstration for an important customer. The old joke around here is
that one of the allowed consequences of undefined behavior is that it
causes demons to fly out of your nose.

Ouch!
Can you tell me which implementation uses such function calls as
recursive main() calls (Chris Torek said so) ?

cheers,
forayer

[Keith Thompson]

"forayer" <th********@hotmail.com> writes:
[...]

Can you tell me which implementation uses such function calls as
recursive main() calls (Chris Torek said so) ?

It's not a matter of "which implementation". C allows main to be
called recursively. It hardly ever makes sense to do 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.

[Chris Torek]

>Chris Torek wrote:

#include <stdio.h>
struct S { char a[1]; };
int main(void) {
struct T { struct S { char a[1000]; } a; };
printf("sizeof(struct S) = %lu\n", (unsigned long)sizeof(struct S));
return 0;
}
(Exercise: what is the most likely output of the above, as both
C and C++? Why is it different?)
In article <11*********************@g47g2000cwa.googlegroups. com>
forayer <th********@hotmail.com> wrote:

1000 using C, and 1 using C++. My money is on scope-resolution
differences between the languages. Please correct me if I am wrong.
Got it in one. Of course, neither 1 nor 1000 are guaranteed
(because the structures may include padding), but they are at
least extremely likely to be different. :-)
... There are machines on which [(*f)(), where f==NULL,] turns
out to be a recursive call to main().

I really didn't know that, thank you. :-)

I saw in another thread that you were wondering where this was the
case. The case I was thinking of in particular occurred on the
VAX running 4.xBSD, but it could occur on any similar machine.
The most basic requirement is that the NULL function pointer must
point to executable code. This was true since NULL on that machine
was 32-zero-bits, and 4BSD had the program starting on page zero
(VMS, by contrast, made page-zero off limits by default, so that
*(char *)0 got a runtime fault, and attempts to call through NULL
also faulted).

The second tricky bit was that location 0 began with a 16-bit
register mask, even though the kernel launched executables by
pointing the program counter to the startup code rather than
executing the VAX's normal subroutine-call instruction, "CALLS".
(The startup code was thus at address 2. As I recall, 0x00 is a
VAX "HALT" instruction, so the two zero bytes at location zero
would have caused trouble if the binary were launched at address
0. However, having the register-save-mask there enables one to
use the VAX's CALLS instruction.)

The final tricky bit was that this recursive call to main()
would only work if the registers were set up properly. I have
forgotten what the register setup was supposed to be, and just
how tolerant this all was (whether by design or coincidence).
I do, however, remember having one program blow up with a stack
overflow, and in the debugger, seeing a seemingly-infinite
sequence of calls starting with the startup code calling main()
which called some functions which eventually called through the
NULL function-pointer which called main(), etc.

One could get the same effect on other machines, for the same
reasons.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Rajan]

Alawna,
though void does not return anything , void* meaning it returns an
address, which can then be cast to any data-type as you may know.

[forayer]

Keith Thompson wrote:

It's not a matter of "which implementation". C allows main to be
called recursively. It hardly ever makes sense to do so.

I was not exactly asking if main() could be called recursively. What I
was asking for was where calls to NULL function pointers would be
treated as recursive main() calls. Chris Torek has given a very good
explantion for this (it has appeared in my news reader, but not yet on
google groups!). As far as making sense for recursive main() calls go,
you should take a look at the winning entry for International
Obfuscated C Code Contest (IOCCC).

P.S.: You're completely right, it makes no sense to use it in any
useful program, but hell, its fun to do this kind of stuff. (I haven't
qouted the code here, not sure if it has already been posted or not. I
will post it if need be)

cheers,
forayer

[Ben Bacarisse]

On Thu, 23 Jun 2005 05:24:02 +0000, Chris Torek wrote:

Chris Torek wrote:

... There are machines on which [(*f)(), where f==NULL,] turns
out to be a recursive call to main().

I really didn't know that, thank you. :-)

I saw in another thread that you were wondering where this was the case.
The case I was thinking of in particular occurred on the VAX running
4.xBSD

If IIRC something similar happened on the ill-fated Perq (a lovely
personal workstation from Three Rivers later aquired by ICL in the UK).
The microcode designers borrowed an idea from ICL mainframes in which each
function was placed in its own page so the top 16 bits of a code address
identified the function and the bottom 16 the offset within it. This made
decoding register dumps very easy.

<aside>It also had the curious property of being word addressed (though,
for compiling C there were, of course, byte access instructions). This
put it in the now very small category of machines in which the cast in
code like:

int x;
char *cp = (char *)&x;

was not just "to keep the compiler happy" (as some people still think) but
was essential since it generated code to convert from one pointer type to
another. I particularly remember the sort program. It was littered with
un-cast pointer conversions and was a pain to port.</aside>

--
Ben.

[Lawrence Kirby]

On Thu, 23 Jun 2005 14:29:22 +0100, Ben Bacarisse wrote:

....

int x;
char *cp = (char *)&x;

was not just "to keep the compiler happy" (as some people still think) but
was essential since it generated code to convert from one pointer type to
another. I particularly remember the sort program. It was littered with
un-cast pointer conversions and was a pain to port.</aside>

What do you mean by an "un-cast pointer conversion"? Most pointer
conversions in C like the one above require a cast, the compiler is
required to issue a diagnostic if the cast is missing. For those
conversions where a cast is not necessary the effect is identical to using
a cast. For example

void *vp = &x;

and

int *a = malloc(100 * sizeof *a);

work fine when int * and void * have different representations.

Or are you referring to some sort of representation punning using pointers
to pointers?

Lawrence