segmentation error

[Bart van Ingen Schenau]

In the real world, "void main()" insures that you don't work anywhere
very long, so no one knows what kind of other mad antics you pull to
make yourself "a bundle of fun."

In the real world, most programmers don't get to write a function
called 'main' (at least not for production code), so they can't screw
up there.

Bart v Ingen Schenau

 

[Walter Roberson]

In the real world, most programmers don't get to write a function
called 'main' (at least not for production code), so they can't screw
up there.

In the future, everyone will void main() for 15 minutes.

 

[Martin Ambuhl]

In the real world, most programmers don't get to write a function
called 'main' (at least not for production code), so they can't screw
up there.

In the real world, a programmer so clueless that he would, given the
chance to write a function called 'main', write "void main()" will
assuredly screw up other things to the point of unemployment.

 

[Richard Bos]

In the real world, a programmer so clueless that he would, given the
chance to write a function called 'main', write "void main()" will
assuredly screw up other things to the point of unemployment.

Oh, if only. But after all these years and with all this evidence,
Microsoft are still in business.

Richard

 

[jaysome]

Oh, if only. But after all these years and with all this evidence,
Microsoft are still in business.

And so are a lot of embedded compiler vendors, who realize that
99.9999999% of their users write code like this:

void main(void)
{
/* loop forever */
for ( ; ; )
{
/* handle whatever */
}
}

I prefer a return type of void for main() in embedded (free-standing)
applications, provided the compiler supports it, of course.

 

[Keith Thompson]

And so are a lot of embedded compiler vendors, who realize that
99.9999999% of their users write code like this:

void main(void)
{
/* loop forever */
for ( ; ; )
{
/* handle whatever */
}
}

I prefer a return type of void for main() in embedded (free-standing)
applications, provided the compiler supports it, of course.

Yes, the advice that main() always returns int really applies only to
hosted implementations, not to freestanding (typically embedded)
implementations. We usually assume here that we're talking about
hosted implementations unless explicitly stated otherwise, for a
couple of reasons: most people who are learning C use hosted
implementations, and most users of freestanding implementations are, I
would guess, more familiar both with the language and with the
vagaries of their particular implementation.

For *any* compiler, you should use only the forms of main that are
explicitly supported (i.e., documented) by the implementation. For a
hosted implementation, this *always* includes the standard forms
int main(void)
and
int main(int argc, char *argv[])
Using any other form may happen to work with some particular
implementation, but it breaks portability for no real benefit.

For a freestanding implementation, there are no standard forms for
main, and you're stuck using whatever the implementation documents.
I've never actually used a freestanding implementation; I'll take your
word for it that "void main(void)" is typical in that domain.

 

[Chris Torek]

I prefer a return type of void for main() in embedded (free-standing)
applications, provided the compiler supports it, of course.

Personally, in such systems I prefer not to call the C entry point
"main" at all. This avoids any confusion.

 

[Keith Thompson]

Keith Thompson wrote:
... snip ...

But so what? Failure to return a value adds nothing. If the
program never returns it doesn't matter. If it does, it does.

I don't understand your point.

If a freestanding implementation supports "void main(void)" but not
"int main(void)", then you *can't* return a value; attempting to do so
would invoke undefined behavior.

For that matter (and I missed this in my earlier followup), in a
freestanding implementation the entry point needn't even be called
"main".

If you want to write a program that will work on either a freestanding
implementation or a hosted implementation, *and* if the freestanding
implementation supports "int main(void)", then you need to use
"int main(void)". Otherwise, all bets are off, and you'll have to
consult the implementation's documentation to see what it supports.

 

[Joe Wright]

Personally, in such systems I prefer not to call the C entry point
"main" at all. This avoids any confusion.

So you'll call it 'void entry(void)' I suppose. To avoid confusion.

 

[David Thompson]

Keith Thompson said:



Unless it's a VAX, of course. Anyway, the way I see it, until people can

It was really VMS, or at least VAX/VMS; not for example BSD/VAX.
And even there it doesn't cause the program itself to malfunction, and
in particular not to segfault, which was the complaint in this thread;
only problems(?) in DCL _after_ the program exits.

grok something as simple as main's return type, there is little point
in trying to teach them anything else. That is why I am getting into
the habit of either ignoring void main posts completely, or pointing
out just that one error and leaving it there.

Certainly void main is wrong (at least hosted), and certainly getting
it right is a pretty low bar for the learner to hurdle (?). But as far
as diagnosing actual problems, I concur with my non-relative.

- formerly david.thompson1 || achar(64) || worldnet.att.net