help w/ c/c++ problem

[Richard]

Fine by me. Arguing with Mr McIntyre seems to be a waste of time[1], and
I have stopped bothering.

When you stoop to stupid insults ike this, you merely demonstrate why
people increasingly argue with you. FWIW I frequently do agree with
you, but naturally only when you're right....

This coming from the self absorbed donkey who posted "STFW" earlier?

Don't make me laugh.

If your abilities matched your self absorption you would be a very
valuable commodity.

 

[Richard]

Nonsense. We're talking about variations that are *explicitly*
permitted by the standard.

Q: surely the real "standard" limitations should be in the std.c
newsgroup?

Can comp.lang.c not meander a *little* bit?

There is more c knowledge here than in a lot of platform specific groups
and people here can indeed help.

 

[Keith Thompson]

Q: surely the real "standard" limitations should be in the std.c
newsgroup?

No. comp.std.c discusses the standard. comp.lang.c discusses the
language defined by that standard.

 

[Richard Bos]

Agreed, but it is there. I prefer to discuss the language as it is,
not as I wish it were.

True, but this part of the Standard means nothing. It does not actually
change the language, because the license given by it was already given
by the larger license of allowing extensions for UB.

There's a big difference. '(int)*ptr=4' is a constraint violation.
'void main(void)' is undefined behavior if the implementation doesn't
document it, perfectly legal if it does.

*Shrug* So substitute another example which does not violate a
constraint. Say, substitute i=i++. Any implementation is equally allowed
to let it mean anything as it is allowed to let void main() mean
something; therefore, void main() is no more, and no less, legal C than
i=i++.

And here's what the C99 Rationale has to say about it:

main is the only function that may portably be declared either
with zero or two arguments. (The number of other functions?
arguments must match exactly between invocation and definition.)
This special case simply recognizes the widespread practice of
leaving off the arguments to main when the program does not access
the program argument strings. While many implementations support
more than two arguments to main, such practice is neither blessed
nor forbidden by the Standard; a program that defines main with
three arguments is not _strictly conforming_ (see J.5.1.).

So the weasel words apparently are primarily intended to allow for a
third parameter, typically envp, but the wording is vague enough to
give silly things like 'void main(void)' equal status with
'int main(int argc, char **argv, char **envp)'.

IOW, it was inserted to allow lax programmers on lax implementations not
to be bothered by their laxness. Does that make it more specifically
good C than other examples of UB? IMO, it does not.

It's interesting that we don't get nearly as many newbies thinking the
envp parameter is standard as we get thinking 'void main(void)' is
standard.

Interesting, possibly, in that it shows that programming teachers these
days are also Microserfs. It should fill one with sadness.

Richard

 

[CBFalconer]

.... snip ...


*Shrug* So substitute another example which does not violate a
constraint. Say, substitute i=i++. Any implementation is equally
allowed to let it mean anything as it is allowed to let void main()
mean something; therefore, void main() is no more, and no less,
legal C than i=i++.

If, even after reading this thread, you think "i = i++;" is legal,
you are much thicker than is initially apparent.

 

[Keith Thompson]

IOW, it was inserted to allow lax programmers on lax implementations not
to be bothered by their laxness.

No, it was inserted to allow support for the three-argument form of
main, which was common practice long before the ANSI C standard was
introduced.

Does that make it more specifically
good C than other examples of UB? IMO, it does not.

Where did I imply that it's "good C"?

Interesting, possibly, in that it shows that programming teachers these
days are also Microserfs. It should fill one with sadness.

Do any Microsoft compilers document 'void main(void)' as an extension?

 

[Keith Thompson]

No, it was inserted to allow support for the three-argument form of
main, which was common practice long before the ANSI C standard was
introduced.

[...]

On further thought, this may not be a very strong argument. The "or
equivalent" weasel words were added in C99, not in C90.

 

[Richard]

If, even after reading this thread, you think "i = i++;" is legal,
you are much thicker than is initially apparent.

What is illegal about it? Undefined possibly. But "illegal"?

Certainly with gcc in c99 mode with pedantic warnings turned on all I
get is

"hello.c:95: warning: operation on ‘b’ may be undefined"

Nothing about it being "illegal".

"may be undefined" <> "illegal"

And as an aside, it strikes me that you shouldn't call people "thick" as
you don't exactly come across as a paragon of programming virtuosity -
rather a somewhat picky fool trying to ingratiate himself with his peers
by bullying newbies.

Have a nice day now.

 

[Richard Bos]

If, even after reading this thread, you think "i = i++;" is legal,
you are much thicker than is initially apparent.

If you think that I think that i=i++ is legal, _you_ are thicker than
you seem. What I do think is that i=i++ invokes UB; void main() invokes
UB; any individual implementation is allowed to define the behaviour of
_any_ case of UB, as its implementor sees fit; and therefore, i=i++ is
_exactly as_ legal as void main(), and vice versa.
Of course, it should by now be apparent that MAO is that both i=i++ and
void main() are illegal C, though each may be legal C-plus-extensions.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

Fix yer sig.

Richard

 

[Chris Dollin]

If, even after reading this thread, you think "i = i++;" is legal,

It /is/ legal: it isn't a constraint violation.

It's undefined behaviour. An implementation can define it to do
something specific. We /rely/ on this property (to define the
undefined) every time we write code that invokes libraries whose
source isn't C, or isn't provided.

[Which is not to say that writing `i = i++` isn't a Bad Thing.]

you are much thicker than is initially apparent.

I think this is kneejerking in an unnecessarily provoking way.

 

[Richard Heathfield]

CBFalconer said:

If, even after reading this thread, you think "i = i++;" is legal,
you are much thicker than is initially apparent.

1) That isn't what Richard Bos said. He said that void main() is no
more, and no less, legal C than i=i++. That is not a claim that either
void main or i=i++ is, or is not, legal. In fact, whether they are
"legal" depends very much on what you mean by "legal". The term is not
defined in the Standard, after all. Both invoke undefined behaviour. If
undefined behaviour is "illegal", then those constructs are illegal. If
it isn't, then they aren't. If it might be, then they might be.

2) He's right.

3) He has a longstanding and hard-earned reputation on this newsgroup as
someone who knows C very well indeed. You do comp.lang.c a disservice
by using insulting language in an attempt to ridicule a knowledgeable
contributor simply because he provided a correct answer that you appear
not to understand.

You owe Richard Bos an apology.

 

[Keith Thompson]

If, even after reading this thread, you think "i = i++;" is legal,
you are much thicker than is initially apparent.

The word "legal" does not appear in the C standard.

'i = i++;' invokes undefined behavior. It does not violate a
constraint, so no diagnostic is required. An implementation *could*
define the behavior of 'i = i++;', making it well-defined for that
implementation (I sincerely hope that no implementation does so).

'void main()' also invokes undefined behavior *unless* the
implementation defines its behavior.

 

[Flash Gordon]

Richard Bos wrote, On 11/07/07 15:21:

If you think that I think that i=i++ is legal, _you_ are thicker than
you seem. What I do think is that i=i++ invokes UB; void main() invokes
UB; any individual implementation is allowed to define the behaviour of
_any_ case of UB, as its implementor sees fit; and therefore, i=i++ is
_exactly as_ legal as void main(), and vice versa.

I would say that this depends on how you define degrees of legality. If
one implementation defines void main() as legal and no implementations
define i=i++ as legal it could be argued that void main() is more legal
is it is legal on one implementation.

Personally I would just consider both illegal and leave it as that, as
you appear to.

Of course, it should by now be apparent that MAO is that both i=i++ and
void main() are illegal C, though each may be legal C-plus-extensions.

I agree with you here, and agree with what I think is your main point,
that void main() should simply be considered illegal and it left at that.

 

[Kenneth Brody]

Richard Bos wrote, On 11/07/07 15:21: [...]

Of course, it should by now be apparent that MAO is that both i=i++ and
void main() are illegal C, though each may be legal C-plus-extensions.

I agree with you here, and agree with what I think is your main point,
that void main() should simply be considered illegal and it left at that.

Well, 5.1.2.2.1 specifically states that, in addition to the two
defined prototypes of main:

int main(void)
and
int main(int argc, char *argv[])

you are allowed:

some other implementation-defined manner

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[¬a\\/b]

The word "legal" does not appear in the C standard.

'i = i++;' invokes undefined behavior. It does not violate a
constraint, so no diagnostic is required. An implementation *could*
define the behavior of 'i = i++;', making it well-defined for that
implementation (I sincerely hope that no implementation does so).

i'm not agree

for "i=i++;"
the options are 2 only
1) not compiling it
2) define it like "++i;"
end.

if it is not "well definite" so one day it does one thing
one other day does another *different* thing: it is the worst
behavior i can immagine

 

[Richard Heathfield]

¬a\/b said:

On Wed, 11 Jul 2007 08:47:28 -0700, Keith Thompson wrote:


i'm not agree

The C Standard isn't about to change just because you disagree with it.

for "i=i++;"
the options are 2 only
1) not compiling it
2) define it like "++i;"
end.

No, there is a third option, which is that the implementation can do
whatever it likes.

if it is not "well definite" so one day it does one thing
one other day does another *different* thing: it is the worst
behavior i can immagine

So don't invoke undefined behaviour, because when you do, that's
precisely the risk you're running.

 

[Flash Gordon]

Kenneth Brody wrote, On 11/07/07 19:59:

Richard Bos wrote, On 11/07/07 15:21: [...]

Of course, it should by now be apparent that MAO is that both i=i++ and
void main() are illegal C, though each may be legal C-plus-extensions.

I agree with you here, and agree with what I think is your main point,
that void main() should simply be considered illegal and it left at that.

Well, 5.1.2.2.1 specifically states that, in addition to the two
defined prototypes of main:

int main(void)
and
int main(int argc, char *argv[])

you are allowed:

some other implementation-defined manner

I'm aware of that, and I agree that an implementation is allowed to
define void main(), and that on such an implementation it it is allowed.
However, as it is not legal a lot of the time (including on major
implementations) I consider it better to think of it as illegal.

Of course, the standard does not define legal and illegal, so people can
use whatever definition seems most appropriate.

I probably won't respond further on this, since I suspect that no one
will change their minds on this.

 

[Keith Thompson]

I probably won't respond further on this, since I suspect that no one
will change their minds on this.

I was going to change my mind, but I've decided not to.

 

[Chris Dollin]

'i = i++;' invokes undefined behavior. It does not violate a
constraint, so no diagnostic is required. An implementation *could*
define the behavior of 'i = i++;', making it well-defined for that
implementation (I sincerely hope that no implementation does so).

Why? Defining the behaviour as "the compiler will reject the program"
or "when executed, `i = i++` will terminate the program with an
'I TOLD YOU, i = i++ IS UNDEFINED!' message" sounds OK to me.

 

[Army1987]

Why? Defining the behaviour as "the compiler will reject the program"

Do you expect that, if I write
a = a[j]++;
the compiler might foresee the future to understand that i will
someday equal j, and refuse to compile?