Re: Semantic issue: "undefined behavior"
On 9 Okt., 16:28, Seungbeom Kim <musip...@bawi.org> wrote:
Nevin :-] Liber wrote:
Don't you realise that it's not to let others rely on undefined
behaviour, but to make them be aware of the possible outcomes of
relying on undefined behaviour and eventually stay away from it,
that the OP is trying to do here?
It doesn't matter if a compiler of one version behaved this way
on a piece of code whose behaviour is undefined and later a later
version behaved differently on the same code, because what the OP
wants is NOT to rely on a particular behaviour encountered but to
collect *concrete* examples that such code can produce wrong results.
What's wrong with that?
I don't understand why people don't seem to understand or agree
to the OP's goal, even though I feel it's well described and also
legitimate. The OP wants concrete examples, not just theory (that
we all are aware of), to be more convincing. We already know that
UB is bad, but to those who don't, we need to be more convincing
than to just mention the standard or the way things are *supposed*
to be.
I have to admit, that I had (and still have) problems
understanding what the OP actually wants.
The initial posting started with a complain about
people who denounce other people programs of
causing UB, because that would not explain anything
and suggests that there exists usually an ordering
of different violation kinds.
It is typically true, that there exists such an
ordering, but I have no idea of a collection of
such orderings (which is probably also not universally
valid, but I have no idea, because I don't know all
currently existing near-to-conforming compilers) and
whether this would be useful - it tends to play down
the fact that "undefined behaviour" in the context
of standard C++ is actually what it seems to be -
rather unpredictable. So what is wrong with the
information that you can' predict the behaviour
(again: viewed from a general *standard* perspective)?
If he really wants an example, he should provide at
least the addressed compiler and OS information,
because if anyone would describe some concrete
example, this would be probably worthless, because
people tend to say:
"In our company are we fixed on this compiler and
that OS and in this situation there is no problem
at all with this construction - end of the dabate".
Typically some days/weeks/months later there is a
very important customer who wants the program on
another OS and that must happen quickly - otherwise
he will ask your competitor to do that - And
suddenly all breaks, because all the earlier valid
assumptions don't hold anymore. This is so simple.
One project in our company is fixed on the way how
the OS handles what is usually called an access
violation. It's so harmless - I recommend everyone
to use a compiler that simple maps those access
violations and other nasty stuff into "clean"
language exception. Running the same program with
a mingw compiler in standard configuration ends
with an immediate termination - no bye-bye, no
nice dialog "A program error has occurred. Shall
we send an e-mail with a bug report to the
corresponding vendor?" Just press the button - so
easy! Really, no-one should use this mingw compiler
- it makes the things so - how should I name it? -
*nasty*, yes, that is really nasty and an affront
to the honest, unblamable programer.
Further-on the OP ended his posting with this
remark:
"Saying, "the next release of the compiler might end
up causing your program to crash hours later in a
function far, far away" is much more effective than
waving your hands helplessly and saying, "well, it's
just _better_ to write conformant code."
This is nothing new to me. Indeed, this description
has often been given in several postings. So how far
shall we go? Explicitely provide a complicated
program where introducing a known U.B. situation
shall lead to a reproducible and unwanted behaviour?
In my opinion those examples will never instruct
the concerned people. These typically find other
ways to get rid of the unwanted behaviour and they
always have arguments that justify there coding
style. They search for compiler flags that make the
program do what they want (This is basically an
important need, but please note in which context
this is done here!) and they are proud to demonstrate
to you that they again have found a hidden/
obscure compiler flag, which you never have known
about.
Please don't understand me wrong. I'm willing to
give any concrete example for a concrete question
and I don't want to blame the OP for this question,
but I don't see it as an invalid categorization to
describe program constructs that cause U.B. according
to the standard as unpredictable.
Greetings from Bremen,
Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]