level of questions for experts only

[Peter Nilsson]

Correct, but to which constraint violation do you refer?

Take your pick.

2 EXAMPLE An implementation shall issue a diagnostic for the
translation unit:

char i;
int i;

because in those cases where wording in this International Standard
describes the behavior for a construct as being both a constraint
error and resulting in undefined behavior, the constraint error shall
be diagnosed.

That will do nicely.

Arguing that it is the constraint violation which is being diagnosed, not
the undefined behaviour, seems a rather moot point.

 

[Christopher Benson-Manica]

Since there's no opportunity in the general case to check this during
compilation, the compiler isn't required to check it in the special
case of passing a string literal. It's good that gcc gives a warning,
but it's not required to.

Oh I see. Thanks... (please excuse me while I feel stupid for a bit )

 

[Arthur J. O'Dwyer]

Take your pick.

Okay, now *I'm* confused. Jack's statement was actually made
in the context of the C statement

printf("%%%%%") ;

which contains no constraint violation. So did you (Peter)
just randomly decide to explain under what conditions
diagnostics are required, just in case somebody didn't know?
or is there some method to your madness that none of us can
see -- e.g., there being a constraint violation in the line

printf("%%%%%");

?

-Arthur

 

[Mike Wahler]

Okay, now *I'm* confused. Jack's statement was actually made
in the context of the C statement

printf("%%%%%") ;

which contains no constraint violation. So did you (Peter)
just randomly decide to explain under what conditions
diagnostics are required, just in case somebody didn't know?
or is there some method to your madness that none of us can
see -- e.g., there being a constraint violation in the line

printf("%%%%%");

?

Arthur: Thanks for taking time to say that for me,
so I don't need to.

-Mike

 

[Keith Thompson]

Oh I see. Thanks... (please excuse me while I feel stupid for a bit )

We all get used to it around here. }

 

[goose]

<snipped>


ooooh ... i just cannot resist

I'll rewrite your questions like they would have been posed by a sane
person.

Hello, respond if you are on all level of questions.


How can a self-deletable .exe file delete itself on some future date
and time without invoking the .exe file itself?

thats an easy one. you hand the sysad for the machine a battle-axe,
and tell him when you want the .exe file deleted

If we want any wildcard characters in command line arguments to be
appropriately expanded, are we required to make any special provision?
If yes, which?


Why printf("%%%%%"); outputs %%%?

because its a well-known fact that printf cannot count past three.
studies are currently being done in this field (by those who got
too bored with reality tv) to understand why printf cannot count past
three.

How to run a .obj file without previously creating any .exe file?

an easy way to get anything/anyone to run is to place a large, fierce
yet slow *enough* dog behind them/it.

What is a classical class? (For C++)

thats the one that i flunked out in second-year
on campus. ROSY, dont worry too much about the
"C++" bit of the question. they just put that in
there to confuse you.

<snipped many important rules that i unfortunately break sometimes>

goose,
I've got the body of a 25-year old ... and its not
even against her will either

 

[Mark McIntyre]

No. It invokes undefined behaviour.

Indeed. I should have said so.

Your implementation may stop
translation, issue a diagnostic, print %%%, print %%, print "Strength is
irrelevant, resistance is futile!" and assimilate you, transfer all your
money to my bank account, nuke Labrador, or whatever.

All true. The most likely however is that it'll get ignored.

 

[Peter Nilsson]

I see now that I should have prefixed my reply...

Although, this is not true in general.

Okay, now *I'm* confused. Jack's statement was actually made
in the context of the C statement

printf("%%%%%") ;

which contains no constraint violation.

And mine was made with that context removed. I wasn't trying to misrepresent
Jack, I was merely focusing on a statement which drew my attention.

So did you (Peter)
just randomly decide to explain under what conditions
diagnostics are required, just in case somebody didn't know?

Lose the 'randomly' and you have it.

I decided to explain (rather poorly as it seems) that certain forms of
undefined behaviour do indeed *require* a diagnostic. [printf format
specifiers are not part of that list though.]

 

[Peter Nilsson]

Arthur: Thanks for taking time to say that for me,
so I don't need to.

Well, I guess I'm mad in thinking that certain forms of undefined behaviour
do indeed require diagnostics. So be it.

 

[Mike Wahler]

Well, I guess I'm mad

I doubt mad, but perhaps misinformed or misunderstanding.

in thinking that certain forms of undefined behaviour
do indeed require diagnostics.

What brought you to that conclusion?

So be it.

So fix it.

-Mike

 

[Mike Wahler]

I see now that I should have prefixed my reply...

Although, this is not true in general.

Restoring context:

... an implementation is NEVER required to diagnose undefined behavior.

Peter Nillson replied:

A constraint violation requires a diagnostic.

So you say you should have prefaced your reply with
"Although, this is not true in general."

Which gives us:

... an implementation is NEVER required to diagnose undefined behavior.

Peter Nillson replied:

Although, this is not true in general,
A constraint violation requires a diagnostic.

So in essence you just said, "What I'm about to say is
not true in general", and then made an assertion.
In which case I'd have expected you to at least
say under what circumstances it *is* true.

Don't bother, there are no such circumstances. When
I saw Jack make his assertion, I personally gave him
the credibility he's earned here. But 'just in case'
I checked the standard. It supports his statement
100%.

And how you got from 'undefined behavior' to
'constraint violation', I don't know. They're
two separate issues.

And mine was made with that context removed. I wasn't trying to misrepresent
Jack, I was merely focusing on a statement which drew my attention.

Context is always important. Always.

Lose the 'randomly' and you have it.

So that gives us:

"So did you (Peter) just decide to explain under what conditions
diagnostics are required, just in case somebody didn't know?"

To which you now seem to be replying in the affirmative.
Perhaps you 'decided' to explain, but you never explained.
What conditions are they?

I decided to explain (rather poorly as it seems)

Not even poorly. An assertion is not an explanation.

Again, all you said was:
"A constraint violation requires a diagnostic."
That is not an explanation.

that certain forms of
undefined behaviour

Which 'certain forms'? Not only did you not explain,
you did not enumerate these forms.

do indeed *require* a diagnostic.

None do. If you feel otherwise, please cite them
along with supporting material from the standard.

[printf format
specifiers are not part of that list though.]

Of course not. No entity at all can be part of an empty set.

-Mike

 

[Arthur J. O'Dwyer]

[Peter should have said:]

Although, this is not true in general.

And mine was made with that context removed. I wasn't trying to misrepresent
Jack, I was merely focusing on a statement which drew my attention.

I decided to explain (rather poorly as it seems) that certain forms of
undefined behaviour do indeed *require* a diagnostic. [printf format
specifiers are not part of that list though.]

And I say again, *no*! Undefined behavior is by definition undefined,
and thus requires *nothing*, including diagnostics. Constraint
violations, OTOH, *do* require diagnostics. They're different
categories altogether, and AFAIK they're completely disjoint.

If you can come up with a construction which exhibits both a
constraint violation *and* undefined behavior, as part of the
same construct (I'm not really sure what that means anyway),
or an example of undefined behavior that requires a diagnostic,
then I'll have learned something. But AFAIK constraint violations
are one thing and undefined behavior is another thing, and never
the twain shall meet.

-Arthur

 

[pete]

[Peter should have said:]

Although, this is not true in general.

And mine was made with that context removed. I wasn't trying to misrepresent
Jack, I was merely focusing on a statement which drew my attention.

I decided to explain (rather poorly as it seems) that certain forms of
undefined behaviour do indeed *require* a diagnostic. [printf format
specifiers are not part of that list though.]

And I say again, *no*! Undefined behavior is by definition undefined,
and thus requires *nothing*, including diagnostics. Constraint
violations, OTOH, *do* require diagnostics. They're different
categories altogether, and AFAIK they're completely disjoint.

If you can come up with a construction which exhibits both a
constraint violation *and* undefined behavior, as part of the
same construct (I'm not really sure what that means anyway),
or an example of undefined behavior that requires a diagnostic,
then I'll have learned something. But AFAIK constraint violations
are one thing and undefined behavior is another thing, and never
the twain shall meet.

int array[1], *pointer = (char*)array;

 

[Irrwahn Grausewitz]

[Peter should have said:]

Although, this is not true in general.

And mine was made with that context removed. I wasn't trying to misrepresent
Jack, I was merely focusing on a statement which drew my attention.

I decided to explain (rather poorly as it seems) that certain forms of
undefined behaviour do indeed *require* a diagnostic. [printf format
specifiers are not part of that list though.]

And I say again, *no*! Undefined behavior is by definition undefined,
and thus requires *nothing*, including diagnostics. Constraint
violations, OTOH, *do* require diagnostics. They're different
categories altogether, and AFAIK they're completely disjoint.

If you can come up with a construction which exhibits both a
constraint violation *and* undefined behavior, as part of the
same construct (I'm not really sure what that means anyway),
or an example of undefined behavior that requires a diagnostic,
then I'll have learned something. But AFAIK constraint violations
are one thing and undefined behavior is another thing, and never
the twain shall meet.

ISO/IEC 9899:1999
5.1.1.3 Diagnostics
[...]
2 EXAMPLE An implementation shall issue a diagnostic for the
translation unit:
char i;
int i;
because in those cases where wording in this International
Standard describes the behavior for a construct as being both
a constraint error and resulting in undefined behavior, the
constraint error shall be diagnosed.

Regards

Irrwahn

 

[Arthur J. O'Dwyer]

... an implementation is NEVER required to diagnose
undefined behavior.
I decided to explain (rather poorly as it seems) that certain forms of
undefined behaviour do indeed *require* a diagnostic. [printf format
specifiers are not part of that list though.]

If you can come up with a construction which exhibits both a
constraint violation *and* undefined behavior, as part of the
same construct (I'm not really sure what that means anyway),
or an example of undefined behavior that requires a diagnostic,
then I'll have learned something. But AFAIK constraint violations
are one thing and undefined behavior is another thing, and never
the twain shall meet.

int array[1], *pointer = (char*)array;

Sorry, pete, I don't get it. Is the above undefined or
incorrect in some way?

And thanks, Irrwahn, for pointing out that such examples do
exist, somewhere -- or at least the Standard-writers thought
they did.

-Arthur

 

[Mark Gordon]

On Sun, 28 Sep 2003, Peter Nilsson wrote:

... an implementation is NEVER required to diagnose
undefined behavior.
I decided to explain (rather poorly as it seems) that certain
forms of undefined behaviour do indeed *require* a diagnostic.
[printf format specifiers are not part of that list though.]
If you can come up with a construction which exhibits both a
constraint violation *and* undefined behavior, as part of the
same construct (I'm not really sure what that means anyway),
or an example of undefined behavior that requires a diagnostic,
then I'll have learned something. But AFAIK constraint violations
are one thing and undefined behavior is another thing, and never
the twain shall meet.

int array[1], *pointer = (char*)array;

Sorry, pete, I don't get it. Is the above undefined or
incorrect in some way?

array is an array of ints which is being cast to a char*
*pointer is a pointer to an int which is having a pointer to char
assigned to it.

IIRC you are not allowed to assign a pointer to char to another pointer
type without a cast and I don't think the conversion from int* -> char*
-> int* is guaranteed.

And thanks, Irrwahn, for pointing out that such examples do
exist, somewhere -- or at least the Standard-writers thought
they did.

People are infinitely imaginative when it comes to finding ways to do
things wrong

 

[Peter Nilsson]

On Sun, 28 Sep 2003, Peter Nilsson wrote:

... an implementation is NEVER required to diagnose
undefined behavior.
I decided to explain (rather poorly as it seems) that certain forms of
undefined behaviour do indeed *require* a diagnostic. [printf format
specifiers are not part of that list though.]
If you can come up with a construction which exhibits both a
constraint violation *and* undefined behavior, as part of the
same construct (I'm not really sure what that means anyway),
or an example of undefined behavior that requires a diagnostic,
then I'll have learned something. But AFAIK constraint violations
are one thing and undefined behavior is another thing, and never
the twain shall meet.

So when you see a required diagnostic, it's invariably your belief
that the code is well defined and the warning/error is spurious and
purely there because the standard writers thought the compiler should
say something of no practical significance?!!

And thanks, Irrwahn, for pointing out that such examples do
exist, somewhere -- or at least the Standard-writers thought
they did.

You have Mike to thank for the quote originally. In some random act of
madness you decided to snip it when I first ticked it as a suitable
example!

If you want another I pulled up the very first constraint header 6.4p2
and took about half a second to come up with...

putchar('x);

Such examples are not hard to conceive!

My original point was that a required diagnostic is, more often than
not, as much for the undefined behaviour as for the constraint
violation. Certainly, that's how I've always perceived compiler
errors.

I concede that not all constraint violations are ex-officio invokers
of undefined behaviour. Clearly I got it wrong as a language lawyer.

But I have to ask both Mike and yourself, what do you think
constraints are for? Why bother with them if they only report well
defined code?

 

[ROSY]

ur absolutely *moron* ,stupid .

by now you should have realised that no one in this
group will do your homework for you. trying to engage
them with "expert" questions only further enrages the
regulars.

goose,
did you even read the faq for clc yet ?

 

[Arthur J. O'Dwyer]

Arthur J. O'Dwyer wrote...

So when you see a required diagnostic, it's invariably your belief
that the code is well defined

Depends what you mean. My computer is physically incapable of
producing "undefined" byte values, so my source code is always
well-defined. Of course, if one of my programs violates a
constraint, then my C compiler issues a diagnostic and refuses
to compile the code, as required and allowed, respectively, by
the Standard. So there does not exist any "program", nor any
"behavior", defined or otherwise, associated with a program
which is not correct C. IMHO.

and the warning/error is spurious

'Course not! The error would specify (if I'm lucky) which
constraint had been violated, so I could fix it.

and purely there because the standard writers thought the
compiler should say something of no practical significance?!!

That doesn't make sense. A "C program" which does not compile
is not, technically speaking, a C program. It's *almost* a
program, but if it's not something that a C compiler can accept,
then I wouldn't call it a C program. And in this newsgroup, we
only talk about the "(un)defined behavior" of C programs.

You have Mike to thank for the quote originally. In some random act of
madness you decided to snip it when I first ticked it as a suitable
example!

Did you? Sorry.

If you want another I pulled up the very first constraint header 6.4p2
and took about half a second to come up with...

putchar('x);

How does that invoke UB? In fact, how exactly does that violate
a constraint? I'm having a hard time reading the Standard tonight;
I know there's some prohibition about unterminated character constants
in there somewhere, but I can't find it...

My original point was that a required diagnostic is, more often than
not, as much for the undefined behaviour as for the constraint
violation. Certainly, that's how I've always perceived compiler
errors.

Nope. UB was basically left "undefined" *because* it was so hard
to diagnose. Stuff like modifying string literals, for example.
If it's easy for the compiler to catch, it's almost always given
as a constraint.

But I have to ask both Mike and yourself, what do you think
constraints are for? Why bother with them if they only report well
defined code?

They don't report well-defined code; they report text which is *not*
code -- not C code, anyways. As I see it (slight repetition of above),
we have:

"C programs" with constraint violations: do not compile, thus
are not *really* written in C. E.g., your average C++
program violates several constraints. So does your average
Shakespearean sonnet. So do lots of things that *look* very
similar to real C programs, but contain typos or "thinkos."
C programs which exhibit undefined behavior. These programs
aren't required to elicit diagnostics, but their exact
behavior isn't defined either.
C programs without undefined behavior, which of course can be
further broken down into "conforming," "strictly conforming,"
et cetera. These are programs that AFAIK must always
compile and execute "correctly," without refusing to compile
or blowing things up.

HTH,
-Arthur

 

[Mike Wahler]

ur absolutely *moron* ,stupid .

Now *that* is the way to get folks to help you.

Perhaps if you came back to reality, you might
realize that Joona is one of the brighter folks
around here and could give you lots of quality
help. But I doubt he'll be inclined to when
you insult him.

Good luck!


-Mike