3,549 reputation
514
bio website
location Illinois
age 45
visits member for 2 years, 10 months
seen May 20 at 23:38

Apr
16
comment Undefined behaviour in Java
... (or, for that matter, a C compiler I used in the 1990s for a TI DSP). Do you disagree that it is common for things like graphic decoders to have requirements that invalid input files won't have consequences beyond either a recognizable trap or arbitrary output, and that testing everything to ensure no sequence of data can generate invalid shifts or integer overflows improves much greater overhead than would be the case if such things merely yielded Indeterminate Values?
Apr
16
comment Undefined behaviour in Java
@bames53: The given example was intended for simplicity rather than realism, but such issues are frequently encountered when writing many types of performance-critical code. Further, it strikes me that compiler-vendors are using a very blunt tool which is far less effective than would be a better-designed tool, and which has an excessively-high level of collateral damage. Additionally, the examples I've seen to promote the "necessity" of UB for optimization merely suggest that in exchange for throwing away anything resembling safety one can achieve optimizations comparable to 1960s FORTRAN...
Apr
15
comment Undefined behaviour in Java
...ignore its argument).
Apr
15
comment Undefined behaviour in Java
@bames53: My beef is with the idea that if e.g. code is supposed to call a method if N is less than 128, then shift some value left by N and pass the result to a second method which won't care about its parameter in cases where N is greater than 31, generated code should call the first method even if N was 128 or more. If the purpose of aggressive Undefined-Behavior treatment is to allow optimization, how is that purpose served by forcing programmers to include extra code that the optimizer will likely be unable to remove (since it may have no way of knowing that the called method will...
Apr
15
comment Undefined behaviour in Java
...then Intermediate Value may arbitrarily act as one of them. VERY loose semantics, but quite useful if one is writing a function (e.g. a JPEG decoder) which must yield correct output when given valid input, and may yield arbitrary output when given invalid input, but in any case must not exhibit any Undefined Behavior beyond its output. Such requirements are very common, and 1990s-style constraints allow them to be satisfied much more cheaply than would be possible otherwise.
Apr
15
comment Undefined behaviour in Java
@bames53: I don't follow your last statement. If N is 2147483647, then following the pass where i is 2147483647, it would become Indeterminate Value, and the compiler would be entitled to have the comparison arbitrarily yield true or false as it saw fit. In case my terminology is unclear, I don't mean "an unspecified value" but something much looser. Every calculation or comparison involving Intermediate Value may arbitrarily yield a different result. If any trap representations exist in the same flavor as the Intermediate Value (integer, floating-point, data pointer, or f-pointer), ...
Apr
15
comment Undefined behaviour in Java
@bames53: What is awful about giving programmers ways to write smaller and faster code, which is supposed to be the whole point of optimization? Or allowing programmers to have existing code continue to work the way it always had (a concept which underlies C's historical failure to specify things like two's-complement behavior)? Can you offer examples of real-world-useful optimizations which could not be achieved by a programmer using a compiler that was limited to having things like -1<<4 yield an Indeterminate Value rather than UB? I would genuinely like to see some.
Apr
15
comment Undefined behaviour in Java
...as the consequence of an action, relieving the implementation of any obligations in that regard, but a program shall be deemed standards-compliant if it will work correctly on all legitimate compilers whose documentation is consistent with the program's documented requirements.
Apr
15
comment Undefined behaviour in Java
@bames53: None of the cited advantages would require the level of latitude hypermodern compilers are taking with UB. With the exceptions of out-of-bounds memory accesses and stack overflows, which can "naturally" induce random code execution, I can't think of any useful optimization which would require broader latitude than to say that most UB-ish operations yield indeterminate values (which might behave as though they have "extra bits") and may only have consequences beyond that if an implementation's docs expressly reserve the right to impose such; docs may give "Unconstrained behavior"...
Apr
15
comment Philosophy behind Undefined Behavior
...over those which could offer at least some form of guarantees. To my mind, given int blah(uint16_t x1) { if (x1 < 50000) foo(x1); return x1*65536;} having a trap when x1 is greater than 32767 may be preferable to having it silently overflow, and if a compiler could determine that foo() could not prevent the Undefined Behavior (e.g. by doing a longjmp) I would have no problem with blah(32768) trapping before calling foo, but only if trap behavior is totally undefined would it be legitimate to call foo with a value of 50000.
Apr
15
comment Philosophy behind Undefined Behavior
While I think it would be good for the standard to allow traps for many things it calls UB (e.g. integer overflow), and there are good reasons for it not to require that traps do anything predictable, I would think that from every standpoint imaginable the standard would be improved if it required that most forms of UB must either yield indeterminate value or document the fact that they reserve the right to do something else, without being absolutely required to document what that something else might be. Compilers which made everything "UB" would be legal, but likely disfavored...
Apr
15
comment Philosophy behind Undefined Behavior
It's good for programmers to go through extra efforts to ensure portability in cases where different platforms would inherently do different things, but compiler writers waste everyone's time when they eliminate behaviors which programmers historically could have reasonably expected to be common to all future compilers. Given integers i and n, such that n < INT_BITS and i*(1<<n) would not overflow, I would consider i<<=n; to be clearer than i=(unsigned)i << n;; on many platforms it would be faster and smaller than i*=(1<<N);. What is gained having compilers forbid it?
Apr
15
comment Philosophy behind Undefined Behavior
What I find curious is statements I've seen to the effect of "C assumes that programmers will never engage in undefined behavior"--a fact which has historically not been true. A correct statement would have been "C assumed that programmers would not trigger behavior undefined by the standard unless prepared to deal with the natural platform consequences of that behavior. Given that C was designed as a systems-programming language, a big part of its purpose was to allow programmers to do system-specific things not defined by the language standard; the idea that they'd never do so is absurd.
Apr
14
comment Which arguments pass by value and which pass by reference in Java?
...after local variables foo and bar are passed to a method, it might return with foo holding the address that bar used to have, and vice versa. IT would be unlikely, but if by chance the GC were to run a couple times and the last GC cycle happened to place foo where bar had been earlier and vice versa, such a swap could legitimately happen. The key point would be that if foo identified object #204 before the call, it would still do so afterward, even if the address of that object happened to change.
Apr
14
comment Which arguments pass by value and which pass by reference in Java?
What do you think of my suggestion of saying that class-type variables hold "Object identifiers"? If local variable foo holds "Object #204" before boz(foo), then it will hold "Object #204" afterward. The actual contents of the variables can't be rendered in human-readable form, of course, but I think it's clear that whatever object is the 204th one created since program startup will always be the 204th object created since program startup as long as it exists. I much prefer object-id to address, because it is in fact entirely possible that...
Apr
14
comment Philosophy behind Undefined Behavior
Integer addition is an interesting case; beyond the possibility of trap behavior which in some cases would be useful but could in other cases cause random code execution, there are situations where it would be reasonable for a compiler to make inferences based upon the fact that integer overflow is not specified to wrap. For example, a compiler where int is 16 bits and sign-extended shifts are expensive could compute (uchar1*uchar2) >> 4 using a non-sign-extended shift. Unfortunately, some compilers extend inferences not just to results, but to the operands.
Apr
14
comment Philosophy behind Undefined Behavior
I wonder what drove the changing philosophy of UB from "Allow programmers to use behaviors exposed by their platform" to "Find excuses to let compilers to implement totally wacky behavior"? I also wonder how much such optimizations end up improving code size after code is modified to work under the new compiler? I wouldn't be surprised if in many cases the only effect of adding such "optimizations" to the compiler is to force programmers to write bigger and slower code so as to avoid having the compiler break it.
Apr
14
comment Philosophy behind Undefined Behavior
Unfortunately, however, that has been twisted around such that even code which knows that it's running on a processor that would do something useful in a particular case can't take advantage of such behavior, because compilers may use the fact that the C standard doesn't specify the behavior (although the platform would) to apply bizarro-world rewrites to the code.
Apr
14
comment Philosophy behind Undefined Behavior
Originally, many behaviors were left undefined to allow for the possibility that different systems would do different things, including trigger a hardware trap with a handler that may or may not be configurable (and might, if not configured, cause arbitrarily-unpredictable behavior). Requiring that a left-shift of a negative value not trap, for example, would break any code which was designed for a system where it did and relied upon such behavior. In short, they were left undefined so as not to prevent implementers from provide behaviors they thought were useful.
Apr
13
comment Is it okay to have code smells if it admits an easier solution to another problem?
Given such an interface, it's possible to have code encapsulate objects with any combination of abilities, without having to handle different combinations separately. Segregating the interfaces would make it necessary to write many different proxy classes, since proxies for a type that supports method X couldn't be used to wrap objects that can't X, and proxies that can wrap objects that can't X wouldn't be able to expose method X even if it was wrapping an object that could support it.