Need some explanation

[Richard Heathfield]

Does it say that in the charter for this NG?

Yes.

And before you ask, I have it locked away in a cupboard here at MI5
headquarters, where only authorised personnel are able to read it.

 

[Chris Hills]

Far too much is written on the subject of void main. This is really simple
to get right - even the most trivial reading of the Standard shows that an
int return type is the natural choice for C programs that are intended to
be portable, so why not just use int?

I agree. The only time you would not use int is in a free-standing
system where there is nothing to return to. Otherwise there is no
justification for not doing it.

 

[Chris Hills]

Yes.

Then please post it. Seriously I should be interested to see it.

And before you ask, I have it locked away in a cupboard here at MI5
headquarters, where only authorised personnel are able to read it.

The only MI5 that I am aware of is a Graphics company Mike India 5 Ltd
(co number. 02907648 ) by Junction 2 of the M4.
(used to be www.mi-5.co.uk but it is a blank page now)

Though you do work for a highly connected organisation


I will ask for the charter at next time I am passing the office

 

[pete]

The only MI5 that I am aware of is a Graphics company Mike India 5 Ltd

MI5 is his cover. You can easily deduce from his activities
that he really works for MI6.

http://www.mjnewton.demon.co.uk/bond/jbssfaq.htm

 

[Joe Wright]

MI5 is his cover. You can easily deduce from his activities
that he really works for MI6.

http://www.mjnewton.demon.co.uk/bond/jbssfaq.htm

At MI6 there is Richard Bond, 006-7/8. He is under such deep cover that
nobody knows how to fix his Martini. He drives a really cool 1992 Mazda
Miada. Is that our man?

Welcome back Richard.

 

[Keith Thompson]

I agree. The only time you would not use int is in a free-standing
system where there is nothing to return to. Otherwise there is no
justification for not doing it.

Just out of curiosity, are there any freestanding implementations that
accept
void main(void) { }
that *don't* accept
int main(void) { return 0; }
(with the same effect)? If not, there's even less reason to use void
main() -- though I suppose if you're certain your code will only ever
be compiled on a system that accepts void main(), there's no much
reason not to use it.

 

[Chris Hills]

Just out of curiosity, are there any freestanding implementations that
accept
void main(void) { }
that *don't* accept
int main(void) { return 0; }
(with the same effect)? If not, there's even less reason to use void
main() -- though I suppose if you're certain your code will only ever
be compiled on a system that accepts void main(), there's no much
reason not to use it.

Good point. I am not sure if they would actually accept it. Never tried
it.

However it is incorrect as it implies main can return which it can't.
In many situations a return from main is fatal.

In a free-standing system it would be as incorrect to use int main as it
is to use void main in a hosted environment. Though there is less harm
in using void main in a hosted environment.

The int return in a hosted system is stylistic. There is often nothing
returned so having a void makes no difference. If you do need to return
something then you have to put it in.

In a free-standing system having a return the implication is that the
program could terminate. This is not something you want to have even as
a fleeting thought. Many free standing systems are embedded systems and
safety critical.

Personally I would never write a hosted application without the int
return but I would never put a return type other than void on a free-
standing system.

 

[Walter Roberson]

In a free-standing system it would be as incorrect to use int main as it
is to use void main in a hosted environment.

In a free-standing system having a return the implication is that the
program could terminate. This is not something you want to have even as
a fleeting thought. Many free standing systems are embedded systems and
safety critical.

What you are indicating is that ANSI/ISO should -define- main() for
freestanding implementations as an infinite loop, to prevent
the -possibility- that it might exit -- because the application just
might happen to be safety critical. And that the default signal
handling should be "re-invoke the program entry point" instead of
"terminate".


What was the name of that new language element again?

exit_from_embedded_program_Yes_Yes_Yes_I_have_thought_about_the_possible_implact_on_safety_and_I_still_want_to_do_it_and_I_will_take_personal_responsibility (
struct *Here_are_my_lawyers_contact_details_so_I_can_be_personally_sued_if_I_was_wrong_and_should_not_have_allowed_the_program_to_exit )

 

[Chris Torek]

In a free-standing system having a return the implication is that the
program could terminate. ...

Many freestanding system programs *do* terminate, and correctly so.
(Many others do not, also correctly so.) I would argue that this is
irrelevant:

A hosted C system (that conforms to either C89 or C99) is *guaranteed*
to accept, and do something at least marginally useful with, an
"int main" function with a return value that is one of the three
standard values (0, EXIT_SUCCESS, and EXIT_FAILURE).

A freestanding C system need not even *use* a function named
main().

My personal preference (though I admit I do not always get my way
) is to write hosted applications using "int main" and freestanding
applications using *no* function named "main" at all. When it is
done this way, I find there is minimal confusion and maximal
bug-reduction. (I write a lot of code that runs in one or the
other situation, or sometimes even both. When the code needs to
run on both freestanding and hosted systems, the "int main()" piece
is usually quite short, as is the freestanding system's "main-like"
entry point: both set up the environment needed to call the "real"
program start. In most cases, the unused stub -- the function
named main() in the freestanding code, which is unused there because
the program starts in start(); and start() in the hosted code,
which is unused there because the program starts in main() -- can
be left in, although for memory-footprint sake, one may often want
to omit main() in the embedded/freestanding version.)

 

[Richard Heathfield]

Then please post it. Seriously I should be interested to see it.

But hang on, I covered that...

The only MI5 that I am aware of is a Graphics company Mike India 5 Ltd
(co number. 02907648 ) by Junction 2 of the M4.
(used to be www.mi-5.co.uk but it is a blank page now)

Yes, very blank; we're not particularly tolerant of competitors.

Though you do work for a highly connected organisation


I will ask for the charter at next time I am passing the office

Excellent. You will be expected. Please make sure your affairs are in order
before calling.

 

[Richard Bos]

*wide eyes*

Hey, man, welcome back!

Richard

 

[Richard Bos]

Absolutely. Was the OP writing for a freestanding implementation?

I also note for reference that discussion of freestanding
implementations is generally regarded as offtopic here

Not, IYAM, off-topic, but one does expect it to be mentioned explicitly,
since they're so different; IOW, hosted environments are the default.

Richard

 

[CBFalconer]

What you are indicating is that ANSI/ISO should -define- main()
for freestanding implementations as an infinite loop, to prevent
the -possibility- that it might exit -- because the application
just might happen to be safety critical. And that the default
signal handling should be "re-invoke the program entry point"
instead of "terminate".

All of which can be done with no pain whatsoever using the present
standards. If you don't want to exit the program, don't do so. Is
that so hard?

 

[S.Tobias]

I think your parenthesized statement is incorrect. Each
implementation either does or does not document that it accepts void
main(). If it doesn't document it, it's not implementation-defined
for that implementation; if it does, it is.

An implementation is not required to document that it *doesn't*
support void main.

Yes, that's exactly what I meant.

Also, when it documents other `main' forms, it doesn't have to formally
document that it documents them (actually, documenting them per se
can be considered as such documentation).
(Blablabla - I really didn't mean it to be a joke.)

(If it implements it without documenting it, then
a program using void main invokes undefined behavior; documenting what
that behavior is makes it implementation-defined.)
Yes.



Agreed (though "criminal" is a bit overstated).

Okay, I was joking. It's merely a consent to be mutilated. ;-)

That's still an interesting point. Here's what the standard says:

Lawyers... they can never say "yes" or "no"... :-D

[snipped Standard text]

I find the wording ambiguous; the interpretation depends on how the

I agree, but there's also common sense too (which is, unfortunately,
not defined by the Standard, so it's not an argument).

phrases are grouped. There are three options:
[snip]
I don't *think* that was the intent; in particular, I think the
standard intends to allow an implementation to support void main(void)
(but only if it documents it). This is confirmed by 5.1.2.2.3, which
starts with:

If the return type of the main function is a type compatible with
int,

I had been aware of that part. By itself, it doesn't guarentee yet
anything. I thought the Standard could effectively forbid `non-int
main' somewhere else, which was the reason for my original question.

which wouldn't make any sense if the type were required to be
compatible with int.

Also, in past discussions I found objections (valid, IMO) that the Std
does not define what "implementation-defined manner" means (the word
"manner").

So I think the intent is clear, but only with more analysis than
should be necessary. I'd like to see the wording cleaned up a bit,
but that's an issue for comp.std.c, not for comp.lang.c.

Thank you and Richard for all clarifications and wasting your time for me.

 

[Chris Hills]

Not, IYAM, off-topic, but one does expect it to be mentioned explicitly,
since they're so different; IOW, hosted environments are the default.

Given the fact that almost everything that has electricity somewhere
near it has an MCU in ti these days and 99.9% of those contain free-
standing C programs why is the minority hosted platform the default?

After all every PC is just a collection of embedded systems with free-
standing implementations in.. keyboard, mouse, graphics card, network
controller, PSU (even the batteries on lapopt!) etc

 

[Richard Bos]

Given the fact that almost everything that has electricity somewhere
near it has an MCU in ti these days and 99.9% of those contain free-
standing C programs why is the minority hosted platform the default?

Because most questions asked here are about hosted implementations. I
gather that most embedded programming questions are asked in
comp.programming.embedded or something with a similar name.

Richard

 

[Chris Hills]

Because most questions asked here are about hosted implementations. I
gather that most embedded programming questions are asked in
comp.programming.embedded or something with a similar name.

Richard

Yes a lot are asked in the embedded NG but it should not preclude them
from being asked here.

 

[CBFalconer]

Because most questions asked here are about hosted implementations.
I gather that most embedded programming questions are asked in
comp.programming.embedded or something with a similar name.

Try comp.arch.embedded. The embedded world can use conforming C
code, but the inverse does not necessarily apply. By adhering to
the standard here we ensure that the advice given (after proper
vetting) applies to all. Without this restriction every article
would have to be accompanied by a system description, and would
probably not apply to whatever problem the reader has.

 

[Default User]

pete wrote:

MI5 is his cover. You can easily deduce from his activities
that he really works for MI6.

But not a word to the Eskimos.



Brian

 

[Keith Thompson]

Given the fact that almost everything that has electricity somewhere
near it has an MCU in ti these days and 99.9% of those contain free-
standing C programs why is the minority hosted platform the default?

After all every PC is just a collection of embedded systems with free-
standing implementations in.. keyboard, mouse, graphics card, network
controller, PSU (even the batteries on lapopt!) etc

Hosted implementations are the minority in terms of deployed units,
but not necessarily in terms of number of programmers. Also, I
suspect that a lot of C programmers have never been exposed to a
freestanding implementation.

There should be no objection to discussions of C language issues for
freestanding implementations, but since there just don't seem to be
many questions in that area, it would be wise to state explicitly that
you're talking about a freestanding implementation.

I suspect that most embedded programmers are more likely to have
questions about their specific systems than about the C language.