Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > segmentation error

Reply
Thread Tools

segmentation error

 
 
Bart van Ingen Schenau
Guest
Posts: n/a
 
      05-08-2007
Martin Ambuhl wrote:

> 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
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      05-08-2007
In article <(E-Mail Removed)>,
Bart van Ingen Schenau <(E-Mail Removed)> wrote:
>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.
--
All is vanity. -- Ecclesiastes
 
Reply With Quote
 
 
 
 
Martin Ambuhl
Guest
Posts: n/a
 
      05-08-2007
Bart van Ingen Schenau wrote:
> Martin Ambuhl wrote:
>
>> 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.


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.
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      05-09-2007
Martin Ambuhl <(E-Mail Removed)> wrote:

> Bart van Ingen Schenau wrote:
> > Martin Ambuhl wrote:
> >
> >> 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.

>
> 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
 
Reply With Quote
 
jaysome
Guest
Posts: n/a
 
      05-09-2007
On Wed, 09 May 2007 08:01:27 GMT, http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard
Bos) wrote:

>Martin Ambuhl <(E-Mail Removed)> wrote:
>
>> Bart van Ingen Schenau wrote:
>> > Martin Ambuhl wrote:
>> >
>> >> 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.

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


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.

--
jay
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-09-2007
jaysome <(E-Mail Removed)> writes:
> On Wed, 09 May 2007 08:01:27 GMT, (E-Mail Removed) (Richard
> Bos) wrote:
>>Martin Ambuhl <(E-Mail Removed)> wrote:

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

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

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      05-10-2007
In article <(E-Mail Removed)>
jaysome <(E-Mail Removed)> wrote:
>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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-10-2007
CBFalconer <(E-Mail Removed)> writes:
> Keith Thompson wrote:
> ... snip ...
>>
>> 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.

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

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
Joe Wright
Guest
Posts: n/a
 
      05-10-2007
Chris Torek wrote:
> In article <(E-Mail Removed)>
> jaysome <(E-Mail Removed)> wrote:
>> 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.


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

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      05-21-2007
On Mon, 07 May 2007 23:40:43 +0000, Richard Heathfield
<(E-Mail Removed)> wrote:

> Keith Thompson said:
>
> <snip>
>
> > Given the lamentable existence of books that endorce "void main()",
> > and given that many implementations do not reject it, I generally
> > prefer to point out that it's an error *and* to go on and comment on
> > the rest of the code. If a program uses "void main()" and misbehaves,
> > there's probably some *other* reason for it.

>
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
what's reason to have a segmentation error? questions? C Programming 9 03-06-2006 02:21 AM
Re: fclose cause segmentation error Rufus V. Smith C Programming 0 02-17-2005 03:07 PM
Re: fclose cause segmentation error CBFalconer C Programming 2 02-17-2005 02:55 PM
Re: fclose cause segmentation error Rob Morris C Programming 0 02-17-2005 12:12 PM
Modelsim error code 211 : segmentation violation....What to do ??? Oleg VHDL 9 02-27-2004 01:59 PM



Advertisments