Strange - a simple assignment statement shows error in VC++ but worksin gcc !

R

Rainer Weikusat

James Kuyper said:
No. "Not Defined" means "Not defined in this particular context".
[...]

Whether or not that is common English usage, his argument seems to
depend upon misinterpreting "undefined behavior" as prohibiting the
existence of a definition of any kind.

I wasn't writing about anything except 'the C-language', as defined by
'the C-standard'.
 
L

luserXtrog

Richard said:
James Kuyper said:
so
the strongest statement you can make along those lines is to
replace "has" wit [EF BD 88 0A E2 80 9D EF BD 8D EF BD 89 EF
BD 87 EF BD 88 EF BD 94 E3 80 80 EF BD 88 EF BD 81 EF BD 96 EF BD 85
E2 80 9D EF]
Interesting claim! :)

Sorry about that. The text you're referring to was supposed to say

 > replace "has" with "might have".

My newsreader has recently acquired a bug which sometimes causes it to
switch into a mode in which characters are displayed with a different
font while I'm composing a message. I have not yet figured out what
triggers this mode, and nothing I've yet figured out how to do switches
it back to it's original mode except exiting the newsreader and starting
over - closing the message composition window is insufficient.

However, the text is still readable in the message composition window,
and also in the saved copy of the message I posted, though the font is
ugly - I'd hoped that the posted message would also be readable.
However, even my own newsreader doesn't know how to display that text as
it appears on the news server - though what it does display is different
from what you saw.

Google groups shows it in typewriter font!
If you figure out what you're doing let us know.
It'd be great to make sure code samples are laid out monospaced.
 
K

Keith Thompson

luserXtrog said:
James Kuyper said: [...]
the strongest statement you can make along those lines is to
replace "has" wit [EF BD 88 0A E2 80 9D EF BD 8D EF BD 89 EF
BD 87 EF BD 88 EF BD 94 E3 80 80 EF BD 88 EF BD 81 EF BD 96 EF BD 85
E2 80 9D EF]
[...]
Google groups shows it in typewriter font!
If you figure out what you're doing let us know.
It'd be great to make sure code samples are laid out monospaced.

Bad idea. Newsreaders other than GG aren't going to show it that way.
Mine showed me a series of '?' characters in the original article.
 
B

Ben Bacarisse

James Kuyper said:
Richard said:
James Kuyper said:

so
the strongest statement you can make along those lines is to
replace "has" wit [EF BD 88 0A E2 80 9D EF BD 8D EF BD 89 EF
BD 87 EF BD 88 EF BD 94 E3 80 80 EF BD 88 EF BD 81 EF BD 96 EF BD 85
E2 80 9D EF]

Interesting claim! :)

Sorry about that. The text you're referring to was supposed to say
replace "has" with "might have".

In case it helps, my quite recent version if GNUS showed the text
fine. What arrived at my reader was the UTF-8 encoding of these
Unicode characters:

[FULLWIDTH LATIN SMALL LETTER H][RIGHT DOUBLE QUOTATION
MARK][FULLWIDTH LATIN SMALL LETTER M][FULLWIDTH LATIN SMALL LETTER
I][FULLWIDTH LATIN SMALL LETTER G][FULLWIDTH LATIN SMALL LETTER
H][FULLWIDTH LATIN SMALL LETTER T][IDEOGRAPHIC SPACE][FULLWIDTH LATIN
SMALL LETTER H][FULLWIDTH LATIN SMALL LETTER A][FULLWIDTH LATIN SMALL
LETTER V][FULLWIDTH LATIN SMALL LETTER E][RIGHT DOUBLE QUOTATION
MARK][FULLWIDTH FULL STOP]

(everything else was in the ASCII range)
 
J

jameskuyper

Rainer said:
I wasn't writing about anything except 'the C-language', as defined by
'the C-standard'.

And you were talking about undefined behavior, using a meaning for
that phrase quite different from that specified by the C standard. The
precise definition (3.4.3p1) is "behavior, upon use of a nonportable
or erroneous program construct or of erroneous data, for which this
International Standard imposes no requirements". Contrary to what you
said, there's nothing in that definition which prohibits the existence
of requirements imposed by other sources than "this International
Standard", and nothing which prohibits people from knowing what those
other requirements are.

The other requirements that apply will generally differ from one
system to another (except for the requirement that the system obey the
fundamental laws of physics) - but when any particular program is run
on a particular system, it's generally possible (though not
necessarily easy) to find out what at least some of those requirements
are.
 
R

Rainer Weikusat

jameskuyper said:
And you were talking about undefined behavior, using a meaning for
that phrase quite different from that specified by the C standard.

This is a lie.
The precise definition (3.4.3p1) is "behavior, upon use of a nonportable
or erroneous program construct or of erroneous data, for which this
International Standard imposes no requirements". Contrary to what you
said, there's nothing in that definition which prohibits the existence
of requirements imposed by other sources than "this International
Standard",

I have never said anything about this fabric of your imagination, and
I have told you that I WASN'T WRITING ABOUT ANYTHING EXCEPT C at least
three times, once even in the posting you pretend to be replying
to. So, how can it be that you still managed to not understand that?
Vested interest or lack of intellectual capability?
 
J

jameskuyper

Rainer said:
This is a lie.


I have never said anything about this fabric of your imagination, and
I have told you that I WASN'T WRITING ABOUT ANYTHING EXCEPT C at least
three times, once even in the posting you pretend to be replying
to. So, how can it be that you still managed to not understand that?

Possibly because you're using the phrase "I wasn't writing about
anything except C" to mean something other than what it literally
means. When writing about nothing but C, the phrase "'undefined' means
'nobody knows anything about it'" is false, because in fact, in C,
"'undefined' means 'the C standard imposes no requirements'", a very
different statement, from which the statement you actually made cannot
be derived.

I think that you believe that the fact that you're not writing about
anything but C somehow makes the things other than C disappear (such
as other applicable requirements), but that's not how the world works.
This is no different from the fact that the statement "there are no
planets" does not become true just because you're writing only about
C, and the C standard doesn't mention planets. Planets do exist,
requirements are imposed by sources other than the C standard, and
some people do know about what some of those requirements are, even if
you are not writing about anything but C. Unlike planets, the
possibility of requirements imposed by other sources IS mentioned by
the C standard; but those requirements would continue to exist even if
they were not mentioned there.
 
K

Kenny McCormack

And I 'disagree' with the occasional thunderstorm. But for some reason
or another, it keeps raining nevertheless.

IOW, I am resorting to silly analogies.

IOW, I am conceding the argument.
 
K

Keith Thompson

Rainer Weikusat said:
This is a lie.


I have never said anything about this fabric of your imagination, and
I have told you that I WASN'T WRITING ABOUT ANYTHING EXCEPT C at least
three times, once even in the posting you pretend to be replying
to. So, how can it be that you still managed to not understand that?
Vested interest or lack of intellectual capability?

I've been skimming this thread, but I haven't been paying extremely
close attention to it.

Rainer, can you clarify just what point you were trying to make,
preferably without personal attacks?
 
P

Peter Köhlmann

Keith said:
I've been skimming this thread, but I haven't been paying extremely
close attention to it.

Rainer, can you clarify just what point you were trying to make,
preferably without personal attacks?

Why should he make that point over and over again?
 
K

Kenny McCormack

jameskuyper said:
I think that you believe that the fact that you're not writing about
anything but C somehow makes the things other than C disappear (such
as other applicable requirements), but that's not how the world works.
This is no different from the fact that the statement "there are no
planets" does not become true just because you're writing only about
C, and the C standard doesn't mention planets. Planets do exist,
requirements are imposed by sources other than the C standard, and
some people do know about what some of those requirements are, even if
you are not writing about anything but C. Unlike planets, the
possibility of requirements imposed by other sources IS mentioned by
the C standard; but those requirements would continue to exist even if
they were not mentioned there.

(Channelling Ronnie Raygun)

There ya go again, using that there "common sense" thing again...

Doncha know dat ain't allowed in heeyah? This is CLC, where dogmatic
religious principles apply (like they did in the Raygun and subsequent
Pubbie administrations) and common sense is "OT".

Seriously, it was decided long ago that, for the purposes of this
newsgroup (note well that qualification), if it isn't in the holy
standards documents, it doesn't exist. There can be no room for
confusion on this point. So, in the context of this newsgroup, to use
your example, there are no planets.

Again, quite seriously, can anyone disagree with anything I've said in
this post?
 
J

jameskuyper

Peter said:
Keith Thompson wrote: ....

Why should he make that point over and over again?

Making a point, and clarifying a point, are not the same thing.

Making the same point over and over again is pointless; if someone
didn't understand it the first time, repeating it won't do any good.
That's why I've tried (I'm not sure I've alway succeeded) to explain
my point in a different way each time, in the hopes of finding a way
of saying it that makes it clear. Weikusat has fallen into the rut of
repeating "I wasn't writing about anything but C" three times in a
row; a statement which I think is perfectly clear, but which doesn't
convey anything to me that justifies his comments or invalidates my
arguments against them.

It's clear that he's getting pretty frustrated by my failure to
understand that statement in the way he wants me to understand it, but
repeating that statement cannot reasonably be expected to have a
different effect on my understanding than it did the first time it was
made. However, since he does not understand how I could possibly
continue making my statements after having read his, he might
reasonably have presumed that I didn't actually read his statements,
in which case repetition would be a more reasonable response. This
isn't a completely unfair assumption - it's quite clear that
CBFalconer, for instance, often reads only part of the messages he's
responding to.

Well, I did read that statement. I believe I understand what he said;
I'm less sure I understand what he meant by it; except that I'm
reasonably sure that the meaning he attaches to that statement is
different from the meaning carried by the actual words of the
statement. I have a vague idea what it is he actually meant, but not a
sufficiently clear one to suggest alternative wording.
 
P

Phil Carmody

Keith Thompson said:
I've been skimming this thread, but I haven't been paying extremely
close attention to it.

Rainer, can you clarify just what point you were trying to make,
preferably without personal attacks?

I think the first bit of his point that I encountered was this,
upthread 13-ish:

Rainer Weikusat historically wrote:
|> [...]
|>> But i++ is inherently safe - at least on most common archtectures. And
|>> certainly there's nothing complicated going on, it is obvious what
|>> happens.
|> [...]
|>
|> No, it's not inherently safe.
|>
|> int i = INT_MAX;
|> i++;
|>
|> The "i++" in the above invokes undefined behavior.
|
| 'Undefined behaviour' cannot be 'invoked'. The correct statement would
| be 'I [meaning you] have no idea what will happen because of that'.

Feel free to pick up the thread from that point. It's certainly
one that invites a response.

Phil
 
S

Sjouke Burry

Kenny said:
(Channelling Ronnie Raygun)

There ya go again, using that there "common sense" thing again...

Doncha know dat ain't allowed in heeyah? This is CLC, where dogmatic
religious principles apply (like they did in the Raygun and subsequent
Pubbie administrations) and common sense is "OT".

Seriously, it was decided long ago that, for the purposes of this
newsgroup (note well that qualification), if it isn't in the holy
standards documents, it doesn't exist. There can be no room for
confusion on this point. So, in the context of this newsgroup, to use
your example, there are no planets.

Again, quite seriously, can anyone disagree with anything I've said in
this post?
If you include PLANETS.H or SOLARSYSTEM.H,
they certainly exist, according to proper c rules.
 
K

Keith Thompson

Phil Carmody said:
I've been skimming this thread, but I haven't been paying extremely
close attention to it.

Rainer, can you clarify just what point you were trying to make,
preferably without personal attacks?

I think the first bit of his point that I encountered was this,
upthread 13-ish:

Rainer Weikusat historically wrote:
|> [...]
|>> But i++ is inherently safe - at least on most common archtectures. And
|>> certainly there's nothing complicated going on, it is obvious what
|>> happens.
|> [...]
|>
|> No, it's not inherently safe.
|>
|> int i = INT_MAX;
|> i++;
|>
|> The "i++" in the above invokes undefined behavior.
|
| 'Undefined behaviour' cannot be 'invoked'. The correct statement would
| be 'I [meaning you] have no idea what will happen because of that'.

Feel free to pick up the thread from that point. It's certainly
one that invites a response.

Ok, but I already responded to that and explained exactly what I meant
(that "invokes undefined behavior" is verbal shorthand for "the
behavior is undefined").

I don't think anyone other than Rainer can meaningfully respond to my
question about just what point he was trying to make.
 
P

Peter Köhlmann

Keith said:
Phil Carmody said:
I've been skimming this thread, but I haven't been paying extremely
close attention to it.

Rainer, can you clarify just what point you were trying to make,
preferably without personal attacks?

I think the first bit of his point that I encountered was this,
upthread 13-ish:

Rainer Weikusat historically wrote:
|> [...]
|>> But i++ is inherently safe - at least on most common archtectures.
|>> And certainly there's nothing complicated going on, it is obvious
|>> what happens.
|> [...]
|>
|> No, it's not inherently safe.
|>
|> int i = INT_MAX;
|> i++;
|>
|> The "i++" in the above invokes undefined behavior.
|
| 'Undefined behaviour' cannot be 'invoked'. The correct statement
| would be 'I [meaning you] have no idea what will happen because of
| that'.

Feel free to pick up the thread from that point. It's certainly
one that invites a response.

Ok, but I already responded to that and explained exactly what I meant
(that "invokes undefined behavior" is verbal shorthand for "the
behavior is undefined").

You have *such* a way with words...
I don't think anyone other than Rainer can meaningfully respond to my
question about just what point he was trying to make.

And why should that be? Are you the only one who could possibly understand
what you and Rainer have written?
 
K

Keith Thompson

Golden California Girls said:
It is more interesting than that. While "this International
Standard" attempts to not impose a restriction it actually does,
because it does require that other standards exist and by reference
those standards become part of "this International Standard." So if
the manual for the implementation exists and says it generates code
to run on the XYZ processor and the XYZ processor has a manual that
says what happens in the case of integer overflow then "this
International Standard" also says what happens in the case of
integer overflow despite (3.4.3p3) "EXAMPLE An example of undefined
behavior is the behavior on integer overflow."
[...]

I don't think so.

The C standard requires an implementation to document certain choices.
It doesn't require it to document that it generates code to run on the
XYZ processor, or to document, directly or indirectly, what happens on
integer overflow. A vendor can certainly provide whatever additional
documentation it likes, but that extra documentation doesn't become
part of the C standard.

And even if it did, your conclusion doesn't follow. For example,
suppose the FooCC implementation's documentation says that it
generates code for the Foo 4200 processor, and the Foo 4200
processor's documentation says that integer overflow wraps around in
the common two's-complement fashion, so that INT_MAX + 1 == INT_MIN.
The FooCC compiler can still perform optimizations and generate code
based on the assumption that integer overflow does not occur. For
example, for this code fragment:

int i = INT_MAX;
i ++;
puts("Hello");

the compiler could legitimately generate code that never prints
"Hello", because the behavior is undefined. This would not violate
either the C standard, the FooCC documentation, or the Foo 4200
processor documentation.

If the FooCC compiler's documentation states that it doesn't perform
such optimization, but the compiler actually does so, then the
compiler is violating its own documentation -- but that's not a
violation of the C standard.
 
J

jameskuyper

Peter said:
Keith said:
Phil Carmody said:
Rainer Weikusat historically wrote: ....
| 'Undefined behaviour' cannot be 'invoked'. The correct statement
| would be 'I [meaning you] have no idea what will happen because of
| that'.

Feel free to pick up the thread from that point. It's certainly
one that invites a response.

Ok, but I already responded to that and explained exactly what I meant
(that "invokes undefined behavior" is verbal shorthand for "the
behavior is undefined").

You have *such* a way with words... ....
I don't think anyone other than Rainer can meaningfully respond to my
question about just what point he was trying to make.

And why should that be? Are you the only one who could possibly understand
what you and Rainer have written?

No, the point is that Rainer is the only person who can be certain
what point Rainer was trying to make; everyone else will only be
guessing, based upon what Rainer said.

I post my own guesses about what other people mean all the time: this
post is a prime example. I often do so because I think I can find a
different way of saying the same thing, a way that the other person
might not have been able to come up with, which might make it easier
for someone else to understand.

Other times, quite frankly, I explain my guesses about what someone
else meant because I see that the person in question hasn't responded
to a question yet, and I'm impatient to see the next round of
responses. I'm a little surprised by the fact that I can't remember
anyone ever objecting to me giving my own explanation of what I
thought they meant.

My guesses aren't always right; only the person who actually said
something can know for certain what they meant, and that's the point
Keith is making. Sometimes the most useful outcome of posting my best
guess as to what someone meant, is to have the other person say "No,
that's not what I meant".
 
C

CBFalconer

Sjouke said:
Kenny McCormack wrote:
.... snip ...


If you include PLANETS.H or SOLARSYSTEM.H,
they certainly exist, according to proper c rules.

Can we possibly take this as a sign that Kenny has reformed, and
will observe the topicality rules for c.l.c? Time will tell,
meanwhile he is still plonked.

Idiotic cross-posting removed.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,053
Latest member
billing-software

Latest Threads

Top