Need some explanation

[rahul8143]

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

[Suman]

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler? #include <stdio.h> void main() is not a portable standard definition for main, use:
int main(/*int argc, char **argv*/) {
int val=5;
printf("%d %d %d %d",val,--val,++val,val--); /*falling off main, is a rather recent addition C99 onwards, AFAIK,
hence*/
return 0; }
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5 The order in which the arguments to printf are evaluated is *not* the
same across different compiler/system pairs. 2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

You might like to read the FAQ, and some stuff on side-effects and
sequence points.

[Suman]

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

Goto http://www.eskimo.com/~scs/C-faq/s3.html.

[akarl]

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

In the first case the behavior is undefined (evaluation order of
function parameters). The statement in (2) is very hard to read and
should (in practice) be rewritten into something more comprehensible.

Moreover:

- `void main()' is not a valid ANSI C signature for the main function.

- You have not included stdio.h

- Your coding style is inconsistent and the indentation is strange to
say the least.

[John Bode]

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
It's because you are invoking undefined behavior in both cases. Read
the following: http://www.eskimo.com/~scs/C-faq/s3.html

The expression i++ evaluates to the current value of i; the side affect
(i incremented by 1) is applied sometime before the next sequence
point, but it need not be immediately after the expression is
evaluated.

Similarly for ++i; it evaluates to the current value of i + 1, but i is
not necessarily incremented immediately.

There is no requirement on when the side affects are applied other than
it must happen before the next sequence point.

For example, given the statement

i = j++ + ++k;

the following sequence is possible:

t1 <- j
t2 <- k + 1
i <- t1 + t2
j <- j + 1
k <- k + 1

Same thing applies to your printf() statement; there's no sequence
point between the autoincrement/decrement expressions, so the behavior
is undefined, meaning the compiler can do anything it wants.
void main()
You mean int main(void). Strictly speaking, "void main()" is an error.
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

[Christian Kandeler]

akarl wrote:

1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

In the first case the behavior is undefined (evaluation order of
function parameters). The statement in (2) is very hard to read and
should (in practice) be rewritten into something more comprehensible.

The second case is also undefined, for the same reason the first one is
(repeated modifications of an object without an intervening sequence
point).
Christian

[CBFalconer]

ra*******@gmail.com wrote:

1) First how following program get executed i mean how output is
printed and also why following program gives different output in
Turbo C++ compiler and Visual c++ 6 compiler?
void main()
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

Get your C book or the standard and read up on sequence points
and/or parameter evaluation order. This is elementary. And if you
really mean C++ this is not the place.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[akarl]

John Bode wrote:

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?

It's because you are invoking undefined behavior in both cases. Read
the following: http://www.eskimo.com/~scs/C-faq/s3.html

The expression i++ evaluates to the current value of i; the side affect
(i incremented by 1) is applied sometime before the next sequence
point, but it need not be immediately after the expression is
evaluated.

Similarly for ++i; it evaluates to the current value of i + 1, but i is
not necessarily incremented immediately.

There is no requirement on when the side affects are applied other than
it must happen before the next sequence point.

For example, given the statement

i = j++ + ++k;

the following sequence is possible:

t1 <- j
t2 <- k + 1
i <- t1 + t2
j <- j + 1
k <- k + 1

Same thing applies to your printf() statement; there's no sequence
point between the autoincrement/decrement expressions, so the behavior
is undefined, meaning the compiler can do anything it wants.

void main()

You mean int main(void). Strictly speaking, "void main()" is an error.

{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

[Richard Bos]

akarl <fu********@comhem.se> wrote:

John Bode wrote:

ra*******@gmail.com wrote:

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

In a simple case like this, perhaps not; but in the general case, yes.

Richard

[John Bode]

akarl wrote:

John Bode wrote:

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?

It's because you are invoking undefined behavior in both cases. Read
the following: http://www.eskimo.com/~scs/C-faq/s3.html

[snip]

How come statements like these compile when the result is undefined?
Well, "undefined behavior" basically means the compiler is free to
handle the problem in any way it wants to. As soon as the Standard
mandates that the compiler issue a diagnostic or abort, the behavior is
no longer undefined.
Is
it too hard for the compiler to figure out that it results in undefined
behavior?

I'm not a compiler writer by trade, so I can't say for sure. In the
obvious case (i = i++), it shouldn't be too hard. But imagine a case
like this:

foo.c
-----------------------
int foo(int *p, int *q)
{
return (*p)++ + ++(*q);
}

main.c
-----------------------
extern int foo(int *p, int *q);

int main(void)
{
int i, *j, *k;
int x;

k = &i;
i = 5;
j = k;

x = foo(j, k);
return 0;
}

Not only is i aliased by pointers, the foo() function is compiled
separately from the main() function. There's simply no way to detect
that i is being modified more than once between sequence points at
compile time.

Situations like that would be impossible to guard against. That's why
the Standard leaves the behavior "undefined"; there's simply no good
way to catch all instances of this problem at compile time, so no
requirement is placed on the compiler implementor to do so.

[Chris Dollin]

akarl wrote:

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

In general, yes. (I believe GCC spots some simple cases.)

Consider:

... ++*bill + ++*ben ...

This is undefined if bill and ben point to the same location,
but well-defined [assuming no overflow ...] if they don't.

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

[Jirka Klaue]

John Bode:
....

Well, "undefined behavior" basically means the compiler is free to
handle the problem in any way it wants to. As soon as the Standard
mandates that the compiler issue a diagnostic or abort, the behavior is
no longer undefined.

If the undefined behavior is also a constraint violation a diagnostic
must be issued. (3.4.3#2, 5.1.1.3)

Jirka

[Ben Pfaff]

akarl <fu********@comhem.se> writes:

[...for something like x[i++] = i...]
How come statements like these compile when the result is undefined?
Is it too hard for the compiler to figure out that it results in
undefined behavior?

Sufficiently new versions of GCC will often warn about statements
like this.
--
Ben Pfaff
email: bl*@cs.stanford.edu
web: http://benpfaff.org

[Flash Gordon]

akarl wrote:

John Bode wrote:

ra*******@gmail.com wrote:
<snip>

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

In these simple cases it is reasonably obvious there is undefined
behaviour. However, with
val = (*ptra)-- - --(*ptrb)
How can the compiler reliably determine whether there is undefined
behaviour or not?

So the standard does not require that compilers diagnose undefined
behaviour.

However, some compilers *will* diagnose *some* instances of undefined
behaviour if invoked with the correct switches. For example, the with
gcc -Wsequence-point catches a number of these cases, but it is not perfect.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[CBFalconer]

akarl wrote:

.... snip ...
How come statements like these compile when the result is
undefined? Is it too hard for the compiler to figure out that
it results in undefined behavior?

Why should it? It doesn't have to, because things are
syntactically correct. You are always allowed to use a safer
language, such as Pascal or Ada, if you wish. They have been
designed to have the necessary redundancy to detect such things. C
was designed to replace assembly language.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Peter Ammon]

akarl wrote:

John Bode wrote:

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?

It's because you are invoking undefined behavior in both cases. Read
the following: http://www.eskimo.com/~scs/C-faq/s3.html

The expression i++ evaluates to the current value of i; the side affect
(i incremented by 1) is applied sometime before the next sequence
point, but it need not be immediately after the expression is
evaluated.

Similarly for ++i; it evaluates to the current value of i + 1, but i is
not necessarily incremented immediately.

There is no requirement on when the side affects are applied other than
it must happen before the next sequence point.

For example, given the statement

i = j++ + ++k;

the following sequence is possible:

t1 <- j
t2 <- k + 1
i <- t1 + t2
j <- j + 1
k <- k + 1

Same thing applies to your printf() statement; there's no sequence
point between the autoincrement/decrement expressions, so the behavior
is undefined, meaning the compiler can do anything it wants.

void main()

You mean int main(void). Strictly speaking, "void main()" is an error.

{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

How come statements like these compile when the result is undefined? Is
it too hard for the compiler to figure out that it results in undefined
behavior?

The OP's compiler, Turbo C, shipped in 1989 and isn't exactly the
pinnacle of modern compiler technology (no offense to the Borland
engineers who worked hard on it). Modern compilers will give much
better diagnostics.

To wit, gcc 4 catches all the errors in that code when you turn on
maximum warnings.

void main() {
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}

cc -O2 -W -Wall test.c
test.c:2: warning: return type of 'main' is not 'int'
test.c: In function 'main':
test.c:4: warning: implicit declaration of function 'printf'
test.c:4: warning: incompatible implicit declaration of built-in
function 'printf'
test.c:4: warning: operation on 'val' may be undefined
test.c:4: warning: operation on 'val' may be undefined
test.c:4: warning: operation on 'val' may be undefined

-Peter

--
Pull out a splinter to reply.

[Mark McIntyre]

On 8 Jul 2005 03:11:03 -0700, in comp.lang.c , ra*******@gmail.com
wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
main must return an int - void main() is illegal C code.

(snip example of undefined behaviour which is explained in the FAQ)
2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

This is a FAQ. Please read the FAQ, starting with 3.1.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Chris Croughton]

On Thu, 14 Jul 2005 11:35:18 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

On 8 Jul 2005 03:11:03 -0700, in comp.lang.c , ra*******@gmail.com
wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()

main must return an int - void main() is illegal C code.

It isn't 'illegal' (the only place that word is used in the standard is
in the context of an "illegal instruction" raising a signal). It is
implementation defined whether it is permitted in a hosted environment;
in a freestanding environment it may not even describe the entry point
of the program, and if it does whether it is a valid definition is
implementation defined.

I do hope that no government makes certain C code illegal...

Chris C

[Walter Roberson]

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:
:I do hope that no government makes certain C code illegal...

Cryptography, DVD decoders, viruses...
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[osmium]

"Chris Croughton" writes:

I do hope that no government makes certain C code illegal...

Good luck on your campaign to get programmers to speak English. You should
not expect quick results.

[Chris Hills]

In article <is********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.net> writes

On 8 Jul 2005 03:11:03 -0700, in comp.lang.c , ra*******@gmail.com
wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()

main must return an int - void main() is illegal C code.

Main only returns int in a hosted environment.

In free stranding environments there is nothing to return to. So

void main()

Is the only practical real world solution (and quite legal). The entry
point to the C program does not *have* to be called main but for the
majority of debugging tools it needs to be.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Mark McIntyre]

On Thu, 14 Jul 2005 14:35:19 +0100, in comp.lang.c , Chris Croughton
<ch***@keristor.net> wrote:

On Thu, 14 Jul 2005 11:35:18 +0100, Mark McIntyre
<ma**********@spamcop.net> wrote:

main must return an int - void main() is illegal C code.
It isn't 'illegal'

Illegal is CLC shorthand for "disallowed by the C standard" as I'm
sure you well know.
(the only place that word is used in the standard is
in the context of an "illegal instruction" raising a signal). It is
implementation defined whether it is permitted in a hosted environment;

This is a very old topic of discussion. The C99 standard requires main
to return an int in a hosted environment. There's no implementation
defined-ness about it, and I believe its now widely agreed that the
final phrase of 5.1.2.2.1 (1) refers to the arguments of main.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Thu, 14 Jul 2005 18:20:44 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.org> wrote:

Main only returns int in a hosted environment.

In free stranding environments there is nothing to return to

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 (or at least
largely pointless), since there are few requirements placed on such
implementations by the standard.

So

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Chris Croughton]

On Thu, 14 Jul 2005 14:23:00 +0000 (UTC), Walter Roberson
<ro******@ibd.nrc-cnrc.gc.ca> wrote:

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:
:I do hope that no government makes certain C code illegal...

Cryptography, DVD decoders, viruses...

No, those are applications and can be written in any language. I'm
referring to C code itself, like making it a criminal offence to use
goto or break...

Chris C

[Chris Croughton]

On Thu, 14 Jul 2005 08:54:40 -0700, osmium
<r1********@comcast.net> wrote:

"Chris Croughton" writes:

I do hope that no government makes certain C code illegal...

Good luck on your campaign to get programmers to speak English. You
should not expect quick results.

Indeed, even getting them to speak American would be hard <g>...

Chris C

[Chris Croughton]

On Thu, 14 Jul 2005 18:20:44 +0100, Chris Hills
<ch***@phaedsys.org> wrote:

Main only returns int in a hosted environment.

In free stranding
Is that like lightweight threads? <g>
environments there is nothing to return to. So

void main()

Is the only practical real world solution (and quite legal). The entry
point to the C program does not *have* to be called main but for the
majority of debugging tools it needs to be.

I don't think I've come across an embedded debugging tool which cared
what the entry point is called, they seem to only need to know the start
address (if that isn't hardwired by the processor). Certainly the
mobile phone systems I've programmed at that level have had all sorts of
names for the entry point (boot, entry, startup, etc.) at a whim of the
original programmer or designer.

However, there are probably loads of debuggers I haven't used, every
processor manufacture seems to have their own favourites...

Chris C

[Chris Hills]

In article <0c********************************@4ax.com>, Mark McIntyre
<ma**********@spamcop.net> writes

On Thu, 14 Jul 2005 18:20:44 +0100, in comp.lang.c , Chris Hills
<ch***@phaedsys.org> wrote:

Main only returns int in a hosted environment.

In free stranding environments there is nothing to return to

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 (or at least
largely pointless), since there are few requirements placed on such
implementations by the standard.

However there are probably as many free standing implementations as
hosted. Besides who is the authority to say half the C world is off
topic in a C language group.

However I take your point that in SOME areas the freestanding
implementation is unspecified or implementation defined

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[S.Tobias]

Mark McIntyre <ma**********@spamcop.net> wrote:

This is a very old topic of discussion. The C99 standard requires main ^^^^^ to return an int in a hosted environment.
Would you please explain this to me, or give me some pointers
to past discussions where I could read about this myself?

I did google a bit, and found no proof of your assertion.
In fact, opinions on this (coming from the top clc gurus)
varied both ways.
There's no implementation
defined-ness about it, and I believe its now widely agreed that the
final phrase of 5.1.2.2.1 (1) refers to the arguments of main.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Richard Heathfield]

S.Tobias wrote:

Mark McIntyre <ma**********@spamcop.net> wrote:

This is a very old topic of discussion. The C99 standard requires main ^^^^^

to return an int in a hosted environment.

Would you please explain this to me,

Well, if you want your program to be portable, you have to return int.
Implementations are allowed to define behaviours for alternative return
types for main (they were in C90 too, but C99 merely makes this explicit),
so you can argue that void main is implementation-defined, but ONLY for
implementations that define it! In other implementations, it remains
undefined, and so it's not unreasonable to argue that the C99 standard
requires programs-intended-to-be-portable to return int.
or give me some pointers
to past discussions where I could read about this myself?
Pick 20 articles at random from comp.lang.c's archives. I should think that
at least 6 of them will be about void main.

I did google a bit, and found no proof of your assertion.
In fact, opinions on this (coming from the top clc gurus)
varied both ways.

The safe thing to do is go with int main, unless your implementation
actually forbids it (eg freestanding).
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain

[leeaby]

ra*******@gmail.com wrote:

hello,
1) First how following program get executed i mean how output is
printed and also why following program gives different output in Turbo
C++ compiler and Visual c++ 6 compiler?
void main()
{
int val=5;
printf("%d %d %d %d",val,--val,++val,val--);
}
under turbo compiler its giving
4 4 5 5
This is because turbo compiler executes such single line code from
right to left.
i.e., val-- gets first evaluated, next ++val and so on.
val -- prints a '5'(the value of variable val),substract value of 'val'
by 1, so that now val=4
Now ++val gets executed, ++ before val increments val before printing,
so you obtain a '5'.Now val=5
After this -- val gets executed, substracting 1 from val before
printing as said before and you get a '4' at the output.At this point
val=4
So finally val gets printed and you obtain the current value of the
'val' to be 4

It should be noted that though execution takes place from right to
left, printing takes place in the order defined in printf

It should also be noted that void main() is not a good practice, better
use int main() along with a return 0; just before you end the main()
and under visual c++ its
5 5 6 5

2) How to evaluate following statement
int val =5;
val =- --val - val-- - --val;

[S.Tobias]

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

S.Tobias wrote:

Mark McIntyre <ma**********@spamcop.net> wrote:

This is a very old topic of discussion. The C99 standard requires main ^^^^^

to return an int in a hosted environment.

Would you please explain this to me,

Well, if you want your program to be portable, you have to return int.

Oh, please! I didn't ask about portability! Mark McIntyre made
a rather bold assertion that C99 forbids non-int main, and I asked
only about that.
Implementations are allowed to define behaviours for alternative return
types for main
So can I assume that you disagree now with Mark here?
(they were in C90 too,
I don't think so, C90 allowed only two forms, both returning int.
but C99 merely makes this explicit),
so you can argue that void main is implementation-defined, but ONLY for
implementations that define it!
Well, yes, that's exactly what implementation-defined means, doesn't it?
(Everything after "but" is redundant.)
In other implementations, it remains
undefined,
If it's not defined, then it's undefined, sure.
and so it's not unreasonable to argue that the C99 standard
requires programs-intended-to-be-portable to return int.
Yes, and those programs are called "strictly conforming". However
the Standard does not preclude non-portable conforming programs
(Annex J.3 is a guide how to write them).

or give me some pointers
to past discussions where I could read about this myself?

Pick 20 articles at random from comp.lang.c's archives. I should think that
at least 6 of them will be about void main.

Mostly people bashing other people for using non-portable `void main'.
I was looking for some valid arguments why `non-int main' should be
forbidden by C99, and have found none (maybe I haven't searched enough).

I did google a bit, and found no proof of your assertion.
In fact, opinions on this (coming from the top clc gurus)
varied both ways.

The discussions I found were mostly from 2000-2002. Among them you
claiming (citing from my memory) that "the Std never did, and never
will allow `void main'"; one post from Jack Klein saying `void main'
is disallowed in C99. Two (unrelated) posts from Dan Pop explaining that
`void main' is allowed provided that the implementation documents it.
And numerous other people that seemed important and had different
opinions.
The safe thing to do is go with int main, unless your implementation
actually forbids it (eg freestanding).

My question was not about portability, and obviously concerned only
a hosted implementation.

Could you comment on my point of view below. I'm not trying to cover
all `main' issues, just things relevant to this discussion.
C90 disallowed `non-int main' (only two forms were allowed).
Implementations that accepted other forms were not conforming.

C99 allows other (non-portable) forms, provided that the implementation
documents them. For example:
float _Complex main(int n, _Bool [restrict static 10][n],
struct { float _Imaginary im; long long fam[]; } *,
...);
(Yes, that's an ellipsis - why not?)

The exit status is meaningful only when the return type is compatible
with the type `int'.
Arguments `argc' and `argv' have their meaning only when main is
defined as "int main(int argc, char **argv)". Otherwise they haven't:
int main(int argc, char **argv, char **envp)
void main(int argc, char **argv)
In neither of above cases need `argc' and `argv' have their usual
meaning and constraints.

What changed between C90 and C99 is that what was an extension in C90,
can now be allowed, ie. a compiler does not cease to be conforming
when it accepts other (documented) forms of `main'. It's not meaningful
to anyone, but implementors.
What C90 and C99 have in common is that `main' is the function that
starts the program, and returning from the first instance finishes it.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Richard Heathfield]

S.Tobias wrote:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

S.Tobias wrote:

Mark McIntyre <ma**********@spamcop.net> wrote:

This is a very old topic of discussion. The C99 standard requires main
^^^^^
to return an int in a hosted environment.

Would you please explain this to me,
Well, if you want your program to be portable, you have to return int.

Oh, please! I didn't ask about portability! Mark McIntyre made
a rather bold assertion that C99 forbids non-int main, and I asked
only about that.

My interest is in clarifying the facts, not in settling disputes.

Implementations are allowed to define behaviours for alternative return
types for main

So can I assume that you disagree now with Mark here?

You can assume that implementations are allowed to define behaviours for
alternative types for main.

(they were in C90 too,
I don't think so, C90 allowed only two forms, both returning int.

C90 allows any implementation to provide extensions to the language.

"A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any strictly
conforming program."

A strictly conforming program would not be affected by an implementation's
support for void main.

but C99 merely makes this explicit),
so you can argue that void main is implementation-defined, but ONLY for
implementations that define it!
Well, yes, that's exactly what implementation-defined means, doesn't it?
(Everything after "but" is redundant.)

Well, yes and no.

* Implementation-defined behavior --- behavior, for a correct program
construct and correct data, that depends on the characteristics of the
implementation and that each implementation shall document.

void main is not implementation-defined, because implementations are not
required to document void main. Rather, implementations are free to provide
extensions such as void main, provided they document them. (And, of course,
if they choose not to document them, they simply become extensions anyway.)

So nothing has changed in C99. A void main program still works some places,
and not others.

In other implementations, it remains
undefined,

If it's not defined, then it's undefined, sure.

Quite so.

and so it's not unreasonable to argue that the C99 standard
requires programs-intended-to-be-portable to return int.
Yes, and those programs are called "strictly conforming".

Well, I wouldn't claim strict conformance for most of the programs I've
written that were intended to be portable. I'm not that brave.
However
the Standard does not preclude non-portable conforming programs
(Annex J.3 is a guide how to write them).
Fortran programs are conforming C programs. (They are acceptable to gcc,
which is a conforming implementation.) So the term "conforming program" is
not terribly useful.

<snip>

The safe thing to do is go with int main, unless your implementation
actually forbids it (eg freestanding).

My question was not about portability, and obviously concerned only
a hosted implementation.

Then you must consult your documentation. If your C99 implementation (a)
exists!, and (b) documents void main, then void main is "legal" for that
implementation, but that "legality" is non-transferable.

Could you comment on my point of view below. I'm not trying to cover
all `main' issues, just things relevant to this discussion.
C90 disallowed `non-int main' (only two forms were allowed).
Implementations that accepted other forms were not conforming.
No, the behaviour is undefined, so the compiler can do anything it likes,
including accepting the program and doing something reasonable. Bear in
mind that void main is neither a syntax error nor a constraint violation,
so no diagnostic is required. (Better compilers do, however, diagnose
this.)

C99 allows other (non-portable) forms, provided that the implementation
documents them. For example:
float _Complex main(int n, _Bool [restrict static 10][n],
struct { float _Imaginary im; long long fam[]; } *,
...);
(Yes, that's an ellipsis - why not?)
Correct, but a C90 implementation /may/ accept such a form too.

The exit status is meaningful only when the return type is compatible
with the type `int'.
Arguments `argc' and `argv' have their meaning only when main is
defined as "int main(int argc, char **argv)". Otherwise they haven't:
int main(int argc, char **argv, char **envp)
void main(int argc, char **argv)
In neither of above cases need `argc' and `argv' have their usual
meaning and constraints.
Correct.

What changed between C90 and C99 is that what was an extension in C90,
can now be allowed, ie. a compiler does not cease to be conforming
when it accepts other (documented) forms of `main'.
Providing extensions does not make an implementation non-conforming,
provided it handles strictly conforming programs properly.
It's not meaningful
to anyone, but implementors.

There I must disagree. The reason this matters so much is that it's a
question of ownership. Who owns the main() declaration? Answer: not the
programmer! It's an <shout>interface specification</shout>, and both sides
of the interface should adhere to that spec. That's common sense.

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

[Keith Thompson]

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

[...]

so you can argue that void main is implementation-defined, but ONLY for
implementations that define it!

Well, yes, that's exactly what implementation-defined means, doesn't it?
(Everything after "but" is redundant.)

No, it's not redundant.

Consider this program:

void main(void){}

If an implementation's documentation says that void main(void) is
allowed, then the program has implementation-defined behavior on that
implementation. I can be sure that executing this program won't make
demons fly out of my nose (unless the documentation says that it can).

Suppose I try to compile the same program on another implementation,
one that doesn't document void main(void) is allowed. On that
implementation, there is no "other implementation-defined manner" as
stated in 5.1.2.2.1, so the program violates a "shall" outside a
constraint. It therefore invokes undefined behavior, which means it
*can* make demons fly out of my nose. On this implementation there's
nothing implementation-defined going on.

(It may be that the only difference between the two implementations is
their documentation. The undefined behavior on the second
implementation may happen to be the same as the implementation-defined
behavior on the first.)

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

[CBFalconer]

Richard Heathfield wrote:

S.Tobias wrote:

.... snip ...

What changed between C90 and C99 is that what was an extension
in C90, can now be allowed, ie. a compiler does not cease to be
conforming when it accepts other (documented) forms of `main'.

Providing extensions does not make an implementation non-conforming,
provided it handles strictly conforming programs properly.

It's not meaningful to anyone, but implementors.

There I must disagree. The reason this matters so much is that
it's a question of ownership. Who owns the main() declaration?
Answer: not the programmer! It's an <shout>interface
specification</shout>, and both sides of the interface should
adhere to that spec. That's common sense.

Tobias is missing the point that the subject of c.l.c is _portable_
C code, as defined by the standards from K&R through C89, C90, C95,
and C99. If you have to specify the implementation, you are
off-topic here.

Welcome back from your wilderness wanderings, Richard. It has
exceeded 40 days. EGN is going to be suspicious about your MI5
connections.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Richard Heathfield]

CBFalconer wrote:

Richard Heathfield wrote:

The reason this matters so much is that
it's a question of ownership. Who owns the main() declaration?
Answer: not the programmer! It's an <shout>interface
specification</shout>, and both sides of the interface should
adhere to that spec. That's common sense.
Tobias is missing the point that the subject of c.l.c is _portable_
C code, as defined by the standards from K&R through C89, C90, C95,
and C99. If you have to specify the implementation, you are
off-topic here.

He also seems to be missing the point that the Standard's introduction of
optional implementation-defined behaviour for "main() return type" is of a
different /kind/ to normal implementation-defined behaviour.

Welcome back from your wilderness wanderings, Richard. It has
exceeded 40 days.
I think this is getting needlessly Messianic.

EGN is going to be suspicious about your MI5
connections.

I've already modded him down 1000 in my newsreader, on the assumption that
he still hasn't grown up yet. If he ever does, no doubt someone will let me
know. I simply don't have the time at present to indulge in that kind of
nonsense. The man is a sink for all kinds of resources: time, energy,
bandwidth, disk space (for those who archive), and - not least - patience.
I'd rather use those resources in more constructive ways.

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

[S.Tobias]

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

S.Tobias wrote:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

but C99 merely makes this explicit),
so you can argue that void main is implementation-defined, but ONLY for
implementations that define it!

Well, yes, that's exactly what implementation-defined means, doesn't it?
(Everything after "but" is redundant.)

Well, yes and no.

* Implementation-defined behavior --- behavior, for a correct program
construct and correct data, that depends on the characteristics of the
implementation and that each implementation shall document.

void main is not implementation-defined, because implementations are not
required to document void main. Rather, implementations are free to provide
extensions such as void main, provided they document them. (And, of course,
if they choose not to document them, they simply become extensions anyway.)

I think I see what you mean. Other `main' forms are "optionally
implementation defined". (It is not even impl-defined _whether_ an
implementation defines alternative `main's, because implementations
are not required to document that, right?)
I was thinking more-or-less along these lines, but thanks for clarification.

What changed between C90 and C99 is that what was an extension in C90,
can now be allowed, ie. a compiler does not cease to be conforming
when it accepts other (documented) forms of `main'.

Providing extensions does not make an implementation non-conforming,
provided it handles strictly conforming programs properly.

Thank you, I was confused about what "conforming implementation" meant.

So what really changed is that the implementors may now move their
chapter "Accepted `main' forms" from "Extensions" to the part
called "Implementation-defined features"?

It's not meaningful
to anyone, but implementors.

There I must disagree. The reason this matters so much is that it's a
question of ownership. Who owns the main() declaration? Answer: not the
programmer! It's an <shout>interface specification</shout>, and both sides
of the interface should adhere to that spec. That's common sense.

I don't quite understand what you've said and why. What I meant is
that the change in C99 is not very interesting for the programmers
(clients), because whether `void main' is an extension or implementation
defined feature, I still have to find and check it in the missing compiler
documentation (or write one myself). It seems that even implementors
are not affected by the change very much.
So can this discussion be finished with the following conclusion:

Neither C90 nor C99 forbid other `main' forms (including non-int
`main's). They just don't define them, which means that those forms
don't belong to ISO C, and are forbidden in strictly conforming
programs (and writing them in c.l.c is a criminal offence).

In particular, the assertion "the final phrase of 5.1.2.2.1 (1) refers
only to the arguments of main" is false.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Chris Hills]

In article <42***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> writes

Richard Heathfield wrote:

S.Tobias wrote:

... snip ...

What changed between C90 and C99 is that what was an extension
in C90, can now be allowed, ie. a compiler does not cease to be
conforming when it accepts other (documented) forms of `main'.

Providing extensions does not make an implementation non-conforming,
provided it handles strictly conforming programs properly.

It's not meaningful to anyone, but implementors.

There I must disagree. The reason this matters so much is that
it's a question of ownership. Who owns the main() declaration?
Answer: not the programmer! It's an <shout>interface
specification</shout>, and both sides of the interface should
adhere to that spec. That's common sense.

Tobias is missing the point that the subject of c.l.c is _portable_
C code, as defined by the standards from K&R through C89, C90, C95,
and C99. If you have to specify the implementation, you are
off-topic here.

Does it say that in the charter for this NG?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[S.Tobias]

Chris Hills <ch***@phaedsys.org> wrote:

In article <42***************@yahoo.com>, CBFalconer

Tobias is missing the point that the subject of c.l.c is _portable_
C code, as defined by the standards from K&R through C89, C90, C95,
and C99. If you have to specify the implementation, you are
off-topic here.

My questions concerned only the scope of the C Standard (what
it defines, allows and forbids). I don't see how they can be
off-topic here (perhaps c.s.c would be better, but the problem
I wanted to discuss started here).
I have never advocated use of non-portable code.

Besides that, IMHO C doesn't give portability for free, and in order
to write portable programs you have to know what is not portable.
I think questions on what code is non-portable and why, belong
here, too.
Does it say that in the charter for this NG?

It has never been an argument for me.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Keith Thompson]

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:

Richard Heathfield <in*****@address.co.uk.invalid> wrote: [...]

void main is not implementation-defined, because implementations are not
required to document void main. Rather, implementations are free to provide
extensions such as void main, provided they document them. (And, of course,
if they choose not to document them, they simply become extensions anyway.)

I think I see what you mean. Other `main' forms are "optionally
implementation defined". (It is not even impl-defined _whether_ an
implementation defines alternative `main's, because implementations
are not required to document that, right?)
I was thinking more-or-less along these lines, but thanks for clarification.

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

[...]
So can this discussion be finished with the following conclusion:

Neither C90 nor C99 forbid other `main' forms (including non-int
`main's). They just don't define them, which means that those forms
don't belong to ISO C, and are forbidden in strictly conforming
programs (and writing them in c.l.c is a criminal offence).
Agreed (though "criminal" is a bit overstated).
In particular, the assertion "the final phrase of 5.1.2.2.1 (1) refers
only to the arguments of main" is false.

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

The function called at program startup is named main. The
implementation declares no prototype for this function. It shall
be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though
any names may be used, as they are local to the function in which
they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner.

I find the wording ambiguous; the interpretation depends on how the
phrases are grouped. There are three options:

(1) return type of int and no parameters;
(2) ... two parameters;
(3) ... some other implementation-defined manner.

The phrase "return type of int" does not appear explicitly in choice
2, but we know it's required because we're shown the declaration. The
structure of the sentence implies that the "return type of int" is
also implicit in the third choice. In other words, the sentence
can be parsed as:

return type of int and
(1) no parameters;
(2) two parameters;
(3) some other implementation-defined manner.

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,

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

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.

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

[Richard Heathfield]

S.Tobias wrote:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

void main is not implementation-defined, because implementations are not
required to document void main. Rather, implementations are free to
provide extensions such as void main, provided they document them. (And,
of course, if they choose not to document them, they simply become
extensions anyway.)
I think I see what you mean. Other `main' forms are "optionally
implementation defined". (It is not even impl-defined _whether_ an
implementation defines alternative `main's, because implementations
are not required to document that, right?)
I was thinking more-or-less along these lines, but thanks for
clarification.

See Keith's reply for even more clarification.

<snip>
What I meant is
that the change in C99 is not very interesting for the programmers
(clients),
This is certainly true, at least for as long as it takes to make C99
sufficiently portable to be worth programming for. (I generally program in
a subset of C90 and C99, so my programs are C99-ready but not
C99-dependent.)
because whether `void main' is an extension or implementation
defined feature, I still have to find and check it in the missing compiler
documentation (or write one myself). It seems that even implementors
are not affected by the change very much.
The change is even less interesting for those of us who simply use the
canonical form of main.
So can this discussion be finished with the following conclusion:

Neither C90 nor C99 forbid other `main' forms (including non-int
`main's). They just don't define them, which means that those forms
don't belong to ISO C, and are forbidden in strictly conforming
programs (and writing them in c.l.c is a criminal offence).
It isn't so much that they're forbidden in strictly conforming programs, any
more than you're forbidden from scribbling graffiti on a blank wall (if you
own the wall). But once you've done it, the wall isn't blank any more.
Likewise, strictly-conforming + void main -> not strictly-conforming.

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?

In particular, the assertion "the final phrase of 5.1.2.2.1 (1) refers
only to the arguments of main" is false.

Keith dealt with this bit, too.

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

[Richard Heathfield]

Chris Hills wrote:

In article <42***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> writes

Tobias is missing the point that the subject of c.l.c is _portable_
C code, as defined by the standards from K&R through C89, C90, C95,
and C99. If you have to specify the implementation, you are
off-topic here.

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.

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

[Chris Hills]

In article <db**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>, Richard
Heathfield <in*****@address.co.uk.invalid> writes

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 Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <db**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>, Richard
Heathfield <in*****@address.co.uk.invalid> writes

Chris Hills wrote:

In article <42***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> writes

Tobias is missing the point that the subject of c.l.c is _portable_
C code, as defined by the standards from K&R through C89, C90, C95,
and C99. If you have to specify the implementation, you are
off-topic here.

Does it say that in the charter for this NG?

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

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[pete]

Chris Hills wrote:

In article <db**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@address.co.uk.invalid> writes

Chris Hills wrote:

the charter for this NG?

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

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

--
pete

[Joe Wright]

pete wrote:

Chris Hills wrote:

In article <db**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>,
Richard Heathfield <in*****@address.co.uk.invalid> writes

Chris Hills wrote:
the charter for this NG?
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

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.

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

[Keith Thompson]

Chris Hills <ch***@phaedsys.org> writes:

In article <db**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>, Richard
Heathfield <in*****@address.co.uk.invalid> writes

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.

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.

--
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 Hills]

In article <ln************@nuthaus.mib.org>, Keith Thompson <kst-
[e-mail]> writes

Chris Hills <ch***@phaedsys.org> writes:

In article <db**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>, Richard
Heathfield <in*****@address.co.uk.invalid> writes

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.

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.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Walter Roberson]

In article <86**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:

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_thou ght_about_the_possible_implact_on_safety_and_I_sti ll_want_to_do_it_and_I_will_take_personal_responsi bility (
struct *Here_are_my_lawyers_contact_details_so_I_can_be_p ersonally_sued_if_I_was_wrong_and_should_not_have_ allowed_the_program_to_exit )
--
The rule of thumb for speed is:

1. If it doesn't work then speed doesn't matter. -- Christian Bau

[Chris Torek]

In article <86**************@phaedsys.demon.co.uk>
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:

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

[Richard Heathfield]

Chris Hills wrote:

In article <db**********@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>, Richard
Heathfield <in*****@address.co.uk.invalid> writes

Chris Hills wrote:

In article <42***************@yahoo.com>, CBFalconer writes
If you have to specify the implementation, you are
off-topic here.
Does it say that in the charter for this NG?
Yes.

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

But hang on, I covered that...

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)

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 Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
mail: rjh at above domain