undefined behaviour seems wrong and a big error

On Mon, 07 Feb 2005 21:28:30 GMT, Keith Thompson <kst-u@mib.org>
wrote:[color=blue]
>"Romeo Colacitti" <wwromeo@gmail.com> writes:[color=green]
>> Chris Torek wrote:[color=darkred]
>>> In article <4205BD5C.6DC8@mindspring.com>
>>> pete <pfiland@mindspring.com> wrote:[/color][/color]
>[...][color=green][color=darkred]
>>> >If you have
>>> > int array[1];
>>> >then
>>> > array[-1] is an example of an lvalue which doesn't refer
>>> >to an object. The use of such an lvalue would be undefined behavior.
>>>
>>> Again, apparently true in C99, but not (technically) in C89. But
>>> this just means the C89 standard has a defect.
>>>[/color]
>>
>> C99 is worse, because as per the said standard almost every expression
>> that doesn't resolve to an incomplete types or function type is an
>> LVALUE. So something like 2+3 is an lvalue in C99. I'll just modify
>> that errant sentence in the C99, it must obviously be a typo (they
>> forgot to mention that an lvalue "designates an object.")[/color]
>
>Alas, it wasn't a typo. In C90, an lvalue is defined as "an
>expression (with an object type or an incomplete type other than void)
>that designates an object". The flaw in this definition, given
> int *ptr;
>the expression *ptr may or may not designate an object (it doesn't of
>ptr==NULL, for example). So strictly speaking, you can't always
>determine whether an expression is an lvalue until runtime, which
>clearly was not the intent.
>
>C99 attempted to correct this by dropping the absolute requirement
>that an lvalue must designate an object; an lvalue is now "an
>expression with an object type or an incomplete type other than void;
>if an lvalue does not designate an object when it is evaluated, the
>behavior is undefined." Strictly speaking, 42 is an lvalue (it's an
>expression with an object type) -- and evaluating it invokes undefined
>behavior. Again, this clearly was not the intent.[/color]

I don't are aware of compiler science but "undefined behaviour"
is WRONG, I don't see why "undefined behaviour" has to exist
The behaviour has to be only
1) Compiler do not accept the expression: error
or
2) Compiler accept the expression and every conforming compiler
translate that in the same "behaviour"
END

if someone write *s=++*s; and this is your "undefined behaviour"
compiler has not compile...

RoSsIaCrIiLoIA wrote:[color=blue]
>
> I don't are aware of compiler science[/color]

Then what makes you feel you are qualified to offer an opinion on it?
[color=blue]
> but "undefined behaviour"
> is WRONG,[/color]

Yup, so don't invoke it.
[color=blue]
> I don't see why "undefined behaviour" has to exist[/color]

That much is obvious.
[color=blue]
> The behaviour has to be only
> 1) Compiler do not accept the expression: error
> or
> 2) Compiler accept the expression and every conforming compiler
> translate that in the same "behaviour"
> END[/color]

Fine. Go write a language in which that behaviour is observed.
C isn't it.
[color=blue]
> if someone write *s=++*s; and this is your "undefined behaviour"
> compiler has not compile...[/color]

Feel free to write your own C compiler, in which you diagnose
every occurrence of undefined behaviour in an arbitrary C program.

Undefined behavior is never wrong. What ever it does is always right.

In article <v0ds015i4g10hh6jiot1tb9467bdlvbf3n@4ax.com>,
RoSsIaCrIiLoIA <n@esiste.ee> wrote:
....[color=blue]
>I don't are aware of compiler science but "undefined behaviour"
>is WRONG, I don't see why "undefined behaviour" has to exist
>The behaviour has to be only
>1) Compiler do not accept the expression: error
>or
>2) Compiler accept the expression and every conforming compiler
>translate that in the same "behaviour"
>END
>
>if someone write *s=++*s; and this is your "undefined behaviour"
>compiler has not compile...[/color]

That's the philosophy of the C-like language known as "D"
(www.digitalmars.com). The stated idea of that language is that things
should be either right or wrong (not the endless shades of grey that is
the situation in C) and that the compiler is able to tell right from wrong.

Obviously, for better or worse, this is not the situation with C. I think
it would help a lot if those folks who come in and complain that C isn't
Java or Perl (or any other safety-belted language) would, whenever they see
"C" think (and see in their minds) "portable assembler". That would help
them realize how unlikely it is that C could be safety-belted.

# >I don't are aware of compiler science but "undefined behaviour"
# >is WRONG, I don't see why "undefined behaviour" has to exist
# >The behaviour has to be only

You can extend any partial function which is undefined on part of its domain to being
a total function by making it a special value wherever it had been undefined. However
if the function is recursive and not recursively enumerable, there is no known
mechanism which can be guarenteed to find everywhere the partial function is undefined.
(Such a mechanism would be more powerful than a Turing machine.)

You can do a couple things. Declare the function total anyway; restrict yourself to
functions that are re or less powerful; or accept some things are undefined.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
JUSTICE!
Justice is dead.

On Sat, 12 Feb 2005 16:48:44 GMT, RoSsIaCrIiLoIA <n@esiste.ee> wrote:
[color=blue]
>
>I don't are aware of compiler science but "undefined behaviour"
>is WRONG, I don't see why "undefined behaviour" has to exist
>The behaviour has to be only
>1) Compiler do not accept the expression: error
>or
>2) Compiler accept the expression and every conforming compiler
>translate that in the same "behaviour"
>END
>
>if someone write *s=++*s; and this is your "undefined behaviour"
>compiler has not compile...[/color]

the "undefined behaviour" is good and sensible only if it describe one
*extension* of the language *out the ansi standard*

RoSsIaCrIiLoIA wrote:[color=blue]
>
> On Sat, 12 Feb 2005 16:48:44 GMT, RoSsIaCrIiLoIA <n@esiste.ee> wrote:
>[color=green]
> >if someone write *s=++*s; and this is your "undefined behaviour"
> >compiler has not compile...[/color]
>
> the "undefined behaviour" is good and sensible only if it describe one
> *extension* of the language *out the ansi standard*[/color]

Do you think the compiler should diagnose this code?

#include <stdio.h>

void foo(FILE *fp)
{
fflush(fp);
}

If so, why? If not, why not?

"Kenny McCormack" <gazelle@yin.interaccess.com> wrote in message
news:culpv6$hbi$1@yin.interaccess.com...[color=blue]
> In article <v0ds015i4g10hh6jiot1tb9467bdlvbf3n@4ax.com>,
> RoSsIaCrIiLoIA <n@esiste.ee> wrote:
> ...[color=green]
> >I don't are aware of compiler science but "undefined behaviour"
> >is WRONG, I don't see why "undefined behaviour" has to exist
> >The behaviour has to be only
> >1) Compiler do not accept the expression: error
> >or
> >2) Compiler accept the expression and every conforming compiler
> >translate that in the same "behaviour"
> >END
> >
> >if someone write *s=++*s; and this is your "undefined behaviour"
> >compiler has not compile...[/color]
>
> That's the philosophy of the C-like language known as "D"
> (www.digitalmars.com). The stated idea of that language is that things
> should be either right or wrong (not the endless shades of grey that is
> the situation in C) and that the compiler is able to tell right from[/color]
wrong.

Sometimes people misattribute the portability of Java to the fact that it
runs on a virtual machine. It isn't true, the real reason that Java code is
portable is the language designers made a major effort to eliminate
implementation defined, undefined, and unspecified behavior.

There's no reason that a native compiled language cannot be just as portable
as Java is.

Much of the implementation defined, etc., behaviors of C are legacies left
over from how early implementations differed. Some of it is from trying to
improve efficiency on some CPUs, such as whether char's are signed or not.
Portability of C code is achieved by carefully avoiding such things, and one
really has to know C well to do it successfully.

Perhaps the time has come for C (and C++) to make a pass through the
standard and take a hard look at each of these and get rid of as many as
possible. Getting rid of the order-of-evaluation problems of expressions is
probably a good start. The implementation signed-ness of chars is another
one. I don't believe the efficiency reasons for these being implementation
defined are valid any longer.

The D programming language falls somewhere in between C and Java on this
issue. It tries to eliminate as many of these non-portable behaviors as
possible without significantly affecting power or performance. (One that
can't be eliminated is the size in bytes of a pointer, sigh.)

-Walter
www.digitalmars.com/d/ the D Programming Language

On Sun, 13 Feb 2005 13:36:57 -0800, Walter
<walter@digitalmars.nospamm.com> wrote:
[color=blue]
> Sometimes people misattribute the portability of Java to the fact that it
> runs on a virtual machine. It isn't true,[/color]

Correct, the truth is that Java is not portable, not even to the next
version of the SDK in many cases (and try getting Sun code to run on
someone else's JVM). This is likely to be true of any language which is
specified only by a single owner, they can (and do) change the
specification whenever they feel like it.

Contrast with the fuss when a couple of new keywords are suggested for
C, or a deprecated feature is removed.
[color=blue]
> the real reason that Java code is
> portable is the language designers made a major effort to eliminate
> implementation defined, undefined, and unspecified behavior.[/color]

Hah! Try telling that to any of the Java programmers I know.
[color=blue]
> Much of the implementation defined, etc., behaviors of C are legacies left
> over from how early implementations differed. Some of it is from trying to
> improve efficiency on some CPUs, such as whether char's are signed or not.
> Portability of C code is achieved by carefully avoiding such things, and one
> really has to know C well to do it successfully.[/color]

The signedness of char is one of the biggest mistakes in the language.
They should have been defined as unsigned from the start (there's no
reason something that small needs to be signed) and avoided all of the
hassles with extended character sets (and EBCDIC).
[color=blue]
> Perhaps the time has come for C (and C++) to make a pass through the
> standard and take a hard look at each of these and get rid of as many as
> possible. Getting rid of the order-of-evaluation problems of expressions is
> probably a good start. The implementation signed-ness of chars is another
> one. I don't believe the efficiency reasons for these being implementation
> defined are valid any longer.[/color]

I don't believe there ever were efficiency reasons for the signedness of
chars.
[color=blue]
> The D programming language falls somewhere in between C and Java on this
> issue. It tries to eliminate as many of these non-portable behaviors as
> possible without significantly affecting power or performance. (One that
> can't be eliminated is the size in bytes of a pointer, sigh.)[/color]

But is there an agreed specification? Are there compilers for all
platforms?

Chris C

Chris Croughton wrote:
[color=blue]
> I don't believe there ever were efficiency reasons for the signedness of
> chars.[/color]

Not even the behaviour of movb on the PDP-11?

--
Chris "electric hedgehog" Dollin

gazelle@yin.interaccess.com (Kenny McCormack) wrote:
[color=blue]
> In article <v0ds015i4g10hh6jiot1tb9467bdlvbf3n@4ax.com>,
> RoSsIaCrIiLoIA <n@esiste.ee> wrote:[color=green]
> >if someone write *s=++*s; and this is your "undefined behaviour"
> >compiler has not compile...[/color]
>
> That's the philosophy of the C-like language known as "D"
> (www.digitalmars.com). The stated idea of that language is that things
> should be either right or wrong (not the endless shades of grey that is
> the situation in C) and that the compiler is able to tell right from wrong.[/color]

Then the people at Digitalmars know no more of Turing-completenes than
our macro freak does. Nor of the halting problem.

Richard

"Chris Croughton" <chris@keristor.net> wrote in message
news:slrnd117k7.7fu.chris@ccserver.keris.net...[color=blue]
> On Sun, 13 Feb 2005 13:36:57 -0800, Walter[color=green]
> > the real reason that Java code is
> > portable is the language designers made a major effort to eliminate
> > implementation defined, undefined, and unspecified behavior.[/color]
> Hah! Try telling that to any of the Java programmers I know.[/color]

Java has a design goal of 100% portability, but in reality falls a bit short
of that. But it is far more portable than C is.
[color=blue][color=green]
> > Much of the implementation defined, etc., behaviors of C are legacies[/color][/color]
left[color=blue][color=green]
> > over from how early implementations differed. Some of it is from trying[/color][/color]
to[color=blue][color=green]
> > improve efficiency on some CPUs, such as whether char's are signed or[/color][/color]
not.[color=blue][color=green]
> > Portability of C code is achieved by carefully avoiding such things, and[/color][/color]
one[color=blue][color=green]
> > really has to know C well to do it successfully.[/color]
> The signedness of char is one of the biggest mistakes in the language.[/color]

If that's its biggest mistake, than C is truly remarkable <g>. Myself, I
think C's biggest mistake is using #include instead of import.
[color=blue]
> They should have been defined as unsigned from the start (there's no
> reason something that small needs to be signed) and avoided all of the
> hassles with extended character sets (and EBCDIC).[/color]

I agree that now it should be unsigned (and that is what D does). But early
C had to run on machines where it did make a significant performance
difference.
[color=blue][color=green]
> > The D programming language falls somewhere in between C and Java on this
> > issue. It tries to eliminate as many of these non-portable behaviors as
> > possible without significantly affecting power or performance. (One that
> > can't be eliminated is the size in bytes of a pointer, sigh.)[/color]
> But is there an agreed specification?[/color]

Is there an ISO, ANSI, or ECMA standard specification? No. The specification
is at www.digitalmars.com/d/. Whether you agree with it or not is up to you
<g>. In the future, there will surely be a standards body doing a standard
for it.
[color=blue]
> Are there compilers for all platforms?[/color]

All? No. But there are compilers for Win32, Linux, Mac OS X, FreeBSD, and
Cygwin. Since it's been integrated with gcc, a compiler for any platform
that gcc supports is within reach of any interested party.

-Walter
www.digitalmars.com C, C++, D compilers
"code of the nerds"

On Sat, 12 Feb 2005 16:48:44 +0000, RoSsIaCrIiLoIA wrote:

....
[color=blue]
> if someone write *s=++*s; and this is your "undefined behaviour"
> compiler has not compile...[/color]

That could be detected by a compiler. The problem is an expression like
*s=++*t; which fails when s==t, i.e. they point to the same object. This
isn't generally decidable at sompile time so the C standard can't place a
requitement on a compiler to detect it. You are right that the C language
could give a well defined behaviour in that respect but there are
potential efficiency issues with thst aspproach. It is a design decision,
if you prefer another approach, you'll need to find another language that
implements it.

Lawrence