Tell HN: C Experts Panel – Ask us anything about C • Hacker News Board

Re: Tell HN: C Experts Panel – Ask us anything about C

#971

Post by flatfinger » Sun, Apr 19, 2020, 11:12 PM UTC

a1369209993 wrote: post #970

flatfinger wrote: post #969

Earlier quoted context omitted.

> 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…

> I wouldn't describe such things as "behavior characteristic of the environment", `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 ce…

> Yes, clearly.

Unfortunately, the C Standard doesn't specify an abstraction model that is amenable to the optimization of usable programs.

> 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.

The only reason for contention between compiler writers and programmers is a desire to allow compilers to optimized based upon the assumption that a program won't do certain things. The solution to that contention would be to have a means of inviting optimizations in cases where they would be safe and useful, analogous to what `restrict` would be if the definition of "based upon" wasn't so heinously broken.

Re: Tell HN: C Experts Panel – Ask us anything about C

#972

Post by a1369209993 » Mon, Apr 20, 2020, 5:25 AM UTC

flatfinger wrote: post #971

a1369209993 wrote: post #970

Earlier quoted context omitted.

> I wouldn't describe such things as "behavior characteristic of the environment", `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 ce…

> Yes, clearly. Unfortunately, the C Standard doesn't specify an abstraction model that is amenable to the optimization of usable programs. > 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 p…

> to allow compilers to optimized based upon the assumption that a program won't do certain things.

Emphasis mine. This is always wrong. Correct (and thus legitimate-to-optize-based-on) knowledge of program behavior is derived by actually looking at what the program actually does, eg "p can never be NULL because if is was, a previous jz/bz/cmovz pc would have taken us somewhere else"[0]. Optimising "based on" undefined behaviour is only legitimate to the extent that it consists of choosing the most convenient option from the space of concrete realizations of particular undefined behaviour that are consistent with the environment (especially the hardware).

0: Note that I don't say "a previous if-else statement", because when we say "p can never be NULL", we're already in the process of looking for reasons to remove if-else statements.

Re: Tell HN: C Experts Panel – Ask us anything about C

#973

Post by flatfinger » Mon, Apr 20, 2020, 2:12 PM UTC

a1369209993 wrote: post #972

flatfinger wrote: post #971

Earlier quoted context omitted.

> Yes, clearly. Unfortunately, the C Standard doesn't specify an abstraction model that is amenable to the optimization of usable programs. > 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 p…

> to allow compilers to optimized based upon the assumption that a program won't do certain things. Emphasis mine. This is always wrong. Correct (and thus legitimate-to-optize-based-on) knowledge of program behavior is derived by actually looking at what the program actually does , eg "p can never be NULL because if is was, a previous jz/bz/cmovz pc would have taken us somewhere else"[0]. Optimising "based on" undefi…

There are many cases where accommodating weird corner cases would be expensive, and would only be useful for some kinds of program. Requiring that all implementations intended for all kinds of task handle corner cases that won't be relevant for most kinds of tasks would needlessly degrade efficiency. The problem is that there's no way for programs to specify which corner cases they do or don't need.

Re: Tell HN: C Experts Panel – Ask us anything about C

#974

Post by a1369209993 » Mon, Apr 20, 2020, 9:15 PM UTC

flatfinger wrote: post #973

a1369209993 wrote: post #972

Earlier quoted context omitted.

> to allow compilers to optimized based upon the assumption that a program won't do certain things. Emphasis mine. This is always wrong. Correct (and thus legitimate-to-optize-based-on) knowledge of program behavior is derived by actually looking at what the program actually does , eg "p can never be NULL because if is was, a previous jz/bz/cmovz pc would have taken us somewhere else"[0]. Optimising "based on" undefi…

There are many cases where accommodating weird corner cases would be expensive, and would only be useful for some kinds of program. Requiring that all implementations intended for all kinds of task handle corner cases that won't be relevant for most kinds of tasks would needlessly degrade efficiency. The problem is that there's no way for programs to specify which corner cases they do or don't need.

> Requiring that all implementations intended for all kinds of task handle corner cases that won't be relevant for most kinds of tasks would needlessly degrade efficiency.

Yes, that's what undefined behaviour is for. Eg requiring that implementations handle integer overflow needlessly degrades efficiency of the overwhelming majority of tasks where integers do not if fact overflow.

> The problem is that there's no way for programs to specify which corner cases they do or don't need.

Wait, are you just asking (the situationally appropriate equivalent of) `(int32_t)((uint32_t)x+(uint32_t)y)` and/or `#pragma unsafe assert(p!=NULL)`? Because while it's a shame the standard doesn't provide standardized ways to specify these things (as I admitted upthread) programs are prefectly capable of using the former, and implementations are perfectly capable of supporting the latter; I'm just arguing that the defaults should be sensible.

Re: Tell HN: C Experts Panel – Ask us anything about C

#975

Post by dhhwrongagain » Tue, Apr 21, 2020, 3:04 PM UTC

DougGwyn wrote: post #942

dhhwrongagain wrote: post #847

Earlier quoted context omitted.

I agree but he said the types needed to be corrected. As far as I know the types were already correct.

The argument "0" is not automatically converted to the right type unless there is a prototype in scope. It isn't as important in this case because it is highly likely that the appropriate prototype has been #included, but it is a bigger deal if we're dealing with arguments for a variadic function. Anyway, it's good to be reminded what the declared types are.

Are you serious? Of course the question comes with the reasonable assumption that the proper declaration has been made especially since it’s a well known standard function. Additionally memset() is not a variadic function.

You said the types were corrected, you didn’t say you were reminding about the declaration types. The types were correct from the start.

Re: Tell HN: C Experts Panel – Ask us anything about C

#976

Post by flatfinger » Tue, Apr 21, 2020, 5:41 PM UTC

a1369209993 wrote: post #974

flatfinger wrote: post #973

Earlier quoted context omitted.

There are many cases where accommodating weird corner cases would be expensive, and would only be useful for some kinds of program. Requiring that all implementations intended for all kinds of task handle corner cases that won't be relevant for most kinds of tasks would needlessly degrade efficiency. The problem is that there's no way for programs to specify which corner cases they do or don't need.

> Requiring that all implementations intended for all kinds of task handle corner cases that won't be relevant for most kinds of tasks would needlessly degrade efficiency. Yes, that's what undefined behaviour is for. Eg requiring that implementations handle integer overflow needlessly degrades efficiency of the overwhelming majority of tasks where integers do not if fact overflow. > The problem is that there's no way…

In many cases, the semantics programmers would require are much looser than anything provided for by the Standard. For example, if a programmer requires an expression that computes (x \* y / z) when there is no overflow, and computes an arbitrary value with no side effects when there is an overflow, a programmer could write the expression with unsigned and signed casting operators, but that would force a compiler generate machine code to actually perform the multiplication and division even in cases where it knows that y will always be twice z. Under "yield any value with no side effects" semantics, a compiler could replace the expression with (x \* 2), which would be much faster to compute.

Re: Tell HN: C Experts Panel – Ask us anything about C

#977

Post by EdSchouten » Thu, Apr 23, 2020, 8:07 PM UTC

eqvinox wrote: post #102

ux wrote: post #66

Is there any plan to deal with the locale fiasco at some point? Some hints on what I'm referring to can be found here: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... Unrelated, but I also miss a binary constant notation (such as 0b10101)

I haven't read most of that rant, but a thread-local setlocale() would be a godsend. Not sure if that's ISO C or POSIX though.