A question for this group...

[Malcolm McLean]

בת×ריך ×™×•× ×—×ž×™×©×™, 28 ביוני 2012 09:59:51 UTC+1, מ×ת (e-mail address removed):

name one. C is actually pretty good.

Java has no UBs. A Java program is guaranteed to produce the same output onany Java Virtual machine. The guarantee has now been weakened to accomodate different floating point processors.

 

[Heikki Kallasjoki]

בת×ריך ×™×•× ×—×ž×™×©×™, 28 ביוני 2012 09:59:51 UTC+1, מ×ת (e-mail address removed):
Java has no UBs. A Java program is guaranteed to produce the same
output on any Java Virtual machine. The guarantee has now been
weakened to accomodate different floating point processors.

There is no actual "undefined behaviour" that I know of, but that does
not mean there would not be a certain amount of platform-specific or
plain unspecified behaviour, making the "same output on any Java Virtual
machine" statement an obviously false one, even disregarding the
mentioned exception. For example,

System.out.println(java.io.File.separator);

is definitely not guaranteed to produce the same output on all Java
systems.

Other examples of unspecified things include exactly when, or in which
thread finalize() methods are called, exactly how threads will be
scheduled, or whether methods such as Float.valueOf(float f) (that are
specified to "cache frequently requested values") will return a new
instance or not in some particular case. These are all observable
behaviour.

 

[James Kuyper]

There is no actual "undefined behaviour" that I know of, but that does
not mean there would not be a certain amount of platform-specific or
plain unspecified behaviour, making the "same output on any Java Virtual
machine" statement an obviously false one, even disregarding the
mentioned exception. For example,

System.out.println(java.io.File.separator);

is definitely not guaranteed to produce the same output on all Java
systems.

Other examples of unspecified things include exactly when, or in which
thread finalize() methods are called, exactly how threads will be
scheduled, or whether methods such as Float.valueOf(float f) (that are
specified to "cache frequently requested values") will return a new
instance or not in some particular case. These are all observable
behaviour.

Undefined behavior is only a subset of unspecified behavior - is there
any Java construct such that the Java standard "imposes no restrictions"
on the behavior of that construct?

 

[James Kuyper]

On 06/28/2012 08:28 AM, James Kuyper wrote:
....

Undefined behavior is only a subset of unspecified behavior - is there
any Java construct such that the Java standard "imposes no restrictions"
on the behavior of that construct?

What I meant to say is that "*code with* undefined behavior is only a
subset of *code with* unspecified behavior".

The behavior permitted to code in the former category is a superset of
the behavior permitted to code in the latter category.

 

[Malcolm McLean]

בת×ריך ×™×•× ×—×ž×™×©×™, 28 ביוני 2012 13:14:02 UTC+1, מ×ת Heikki Kallasjoki:

For example,

System.out.println(java.io.File.separator);

is definitely not guaranteed to produce the same output on all Java
systems.

Presumably that's regarded as a class which is part of the program, rather than the program itself. If I write two methods called tan(), one of which performs the mathematical operation whilst another switches on a machine ina sun parlour, we wouldn't expect linking the two libraries to have idential results. That's true of almost every programming language.

 

[Andrew Cooper]

x86 32bit assembly

Pure 32bit assembly perhaps, but as soon as you introduce more than 1
processor, there is plenty of undefined and unpredictable behaviour to
be had.

~Andrew

 

[Philip Lantz]

nick_keighley ha scritto...

x86 32bit assembly

If a repeat prefix is used with an instruction other than MOVS, CMPS,
SCAS, LODS, STOS, INS, or OUTS, the behavior is undefined.

If the source operand of BSF is 0, the result is undefined.

If the BSWAP instruction references a 16-bit register, the result is
undefined.

If the value of the source operand of F2XM1 is outside the range -1.0 to
+1.0, the result is undefined.

....

 

[Guest]

If a repeat prefix is used with an instruction other than MOVS, CMPS,
SCAS, LODS, STOS, INS, or OUTS, the behavior is undefined.

If the source operand of BSF is 0, the result is undefined.

If the BSWAP instruction references a 16-bit register, the result is
undefined.

If the value of the source operand of F2XM1 is outside the range -1.0 to
+1.0, the result is undefined.

...

so io_x doesn't even know much about x86 assembler...

 

[Tim Rentsch]

If a repeat prefix is used with an instruction other than MOVS, CMPS,
SCAS, LODS, STOS, INS, or OUTS, the behavior is undefined.

If the source operand of BSF is 0, the result is undefined.

If the BSWAP instruction references a 16-bit register, the result is
undefined.

If the value of the source operand of F2XM1 is outside the range -1.0 to
+1.0, the result is undefined.

I confess I'm not an expert on the fine points of x86
instruction architecture, but it seems likely that these
examples produce indeterminate results rather than truly
being undefined behavior. For example, probably all of them
are guaranteed not to leave virtual mode, regardless of
whatever else may happen. That may not be much of a
restriction, but any restiction means it's not undefined
behavior.

Incidentally, defining an opcode as "reserved for future
use", then defining it in a later family, is also something
I would not count as undefined behavior. It is _always_
true for any defined behavior that it might be changed in a
future revision of the defining document; that doesn't mean
the behavior is undefined, only that a future revision is
free to redefine (or semi-define, or even undefine) it.

 

[David Thompson]

?????? ??? ?????, 28 ????? 2012 13:14:02 UTC+1, ??? Heikki Kallasjoki:
Presumably that's regarded as a class which is part of the program,
rather than the program itself. If I write two methods called tan(),
one of which performs the mathematical operation whilst another
switches on a machine in a sun parlour, we wouldn't expect linking the
two libraries to have idential results. That's true of almost every
programming language.

I'm not sure what 'class which is part of the program, rather than the
program itself' is intended to mean. All Java packages with first
component java or javax, and classes in them such as java.io.File
here, are reserved for definition by Sun^WOracle. System is actually
java.lang.System (because java.lang is automatically visible in all
Java code, unlike all other packages) and thus similarly standard.
Most java.* packages are part of the (JRE) standard library and thus
usable from any Java code; since Java is dynamically linked, a
complete program can only be defined sensibly as a main routine and
everything its execution can -- or more strictly, does -- access.

In C and some older compiled languages there is a global namespace for
'external' (in C, non-static) routines and variables, so yes two
different 'tan's can be a problem. C++ has namespaces which can be
used to disambiguate, but IME people rarely do. Fortran>=90 has
one-level modules, but it's not clear to me how much they are used; a
lot of Fortran code is 'dusty decks' from long before 1990.

Ada and Java have hierarchical package naming, which people do use.
The two tan's in your example would actually be something like:
org.mathlovers.Trigonometry.tan
com.New_You_483.Farrah.tan
and Java the full 'path' is in the .class file and used for dynamic
linking at runtime to get the correct one.

Some languages allow overloads of routines/methods with different
parameter lists. Java distinguishes these in the .class file; C++
typically uses mangled linker names (though the standard doesn't
specify); Ada usually needs a special or modified linker anyway and
can also resolve on expected return type. (Fortran>=90 allows you to
user-define generic names which call different routines depending on
argument types, but those 'specific' routines do have unique names --
although possibly 'private' ones you can't directly use in a call.)

So java.io.File.separator is always, on every valid JVM, a specific
Suncle-defined variable with a platform-dependent value which is in
fact different on different JVMs, falsifying your overbroad claim.
What *is* standard across all platforms in Java is the core language
-- e.g. int arithmetic is 32-bit 2's-complement with wraparound --
except as you said (almost) floating-point in the absence of strictfp;
and a large fraction of the standard library (up to resource limits,
and there Java is at least safe, unlike some C implementations).

Java also has a fair chunk of library functionality altered by locale
(e.g. character encoding, date-time format) or timezone; so does C
(and C++). This is a grey area that makes 'strictly conforming' even
more useless, since it produces different results even on machines of
the same type or users on the same machine, which are intended to be
and usually(?) are all correct.