Can you do anything to push Microsoft to implement recent C standards? Their failure to fully implement even C99 in Visual Studio is holding the language back.
Tell HN: C Experts Panel – Ask us anything about C
521–530 of 978 posts
Re: Tell HN: C Experts Panel – Ask us anything about C
#522Back from lunch. Any West Coasters?
Re: Tell HN: C Experts Panel – Ask us anything about C
#523The syntax used in the following function definition is said to be obsolescent in C11: int f (a, n) int n; int a[n][n]; { return a[n-1][n-1]; } How could one define this function without using the obsolete syntax?
You couldn't in that parameter order. However, you could do this: int f(size_t n, int a[n][n]) { return a[n-1][n-1]; }
(https://godbolt.org/z/DV9c-C)
Btw, that definition was obsolescent in C89 too.
Re: Tell HN: C Experts Panel – Ask us anything about C
#524Earlier quoted context omitted.
This is a common misconception (or poor way of phrasing it, sorry). Compiler implementers don't go looking for instances of undefined behavior in a program with the goal of optimizing it in some way. There is little value in optimizing invalid code. The opposite is the case. But we must write code that relies on the same rules and requirements that programs are held to (and vice versa). When either party breaks those…
> This is a common misconception (or poor way of phrasing it, sorry). Compiler implementers don't go looking for instances of undefined behavior in a program with the goal of optimizing it in some way. There is little value in optimizing invalid code. The opposite is the case. Compilers do deliberately look to optimize loops with signed counters by exploiting UB to assume that they will never wrap.
I'd say both statements are correct.
Compiler implementers are happy when they don't have to care about some edge case because then the code is simpler. Thus, only for unsigned counters there is the extra logic to compile them correctly.
That is my interpretation of "The opposite is the case". Writing a compiler is easier with lots of undefined behavior.
Re: Tell HN: C Experts Panel – Ask us anything about C
#525As a C newbie, will there ever be "safe" C, i.e. no undefined behavior and help with writing code that has less memory related crashes/bugs? For comparison, Rust has the `unsafe { }' block which lets you mark regions of code as being able to do funky stuff. Could we get the opposite for C, i.e. `safe { }' and for an entire file, `#pragma safe'? I have a love-hate relationship with C - I like it for small projects, bu…
I'm pretty happy with C as it is, but I will admit to being surprised that a "minimalistic Rust" hasn't risen to prominence.
I guess what I mean by that is a language that has Rust's hyperactive, strongly opinionated compiler, borrow checker, no NULL, immutable by default, etc, but in a language that is no more syntactically ambitious that C89. I would be way more into a language like that than Rust.
A language that sort of feels like Go, but can actually be used for low-level systems programming.
Re: Tell HN: C Experts Panel – Ask us anything about C
#526Now that C2x plans to make two's complement the only sign representation, is there any reason why signed overflow has to continue being undefined behavior? On a slightly more personal note: What are some undefined behaviors that you would like to turn into defined behavior, but can't change for whatever reasons that be?
> Now that C2x plans to make two's complement the only sign representation, is there any reason why signed overflow has to continue being undefined behavior?
I presume you'd want signed overflow to have the usual 2's-complement wraparound behavior.
One problem with that is that a compiler (probably) couldn't warn about overflows that are actually errors.
For example:
int n = INT_MAX;
/* ... */
n++;
A compiler could have an option to warn about detected overflow/wraparound even if it's well defined. But really, how often do you want wraparound for signed types? In the code above, is there any sense in which INT_MIN is the "right" answer for any typical problem domain?
Re: Tell HN: C Experts Panel – Ask us anything about C
#527Can you do anything to push Microsoft to implement recent C standards? Their failure to fully implement even C99 in Visual Studio is holding the language back.
Not really -- vendors are free to ignore newer releases of the standard that do not meet their customers needs and the committee can't do much about it.
However, as a user, you can help apply pressure on the vendor to support newer standards. For instance, with Microsoft, you could support this feedback request: https://developercommunity.visualstudio.com/idea/387315/add-...
Re: Tell HN: C Experts Panel – Ask us anything about C
#528Can you do anything to push Microsoft to implement recent C standards? Their failure to fully implement even C99 in Visual Studio is holding the language back.
There is little that the C Standards group can do about it. One idea is to write a C Standards conformance into contracts. When I was in the government we often did that, but it still wasn't enough clout.
Re: Tell HN: C Experts Panel – Ask us anything about C
#529Microsoft's "Checked C" seems to be the last attempt to fix C security flaws.
From the outside, after Annex K adoption failure, WG14 doesn't seem to be willing to make C safer in any way.
Are there any plans to take efforts like Checked C in consideration regarding the future of ISO C?
Re: Tell HN: C Experts Panel – Ask us anything about C
#530The syntax used in the following function definition is said to be obsolescent in C11: int f (a, n) int n; int a[n][n]; { return a[n-1][n-1]; } How could one define this function without using the obsolete syntax?
You couldn't in that parameter order. However, you could do this: int f(size_t n, int a[n][n]) { return a[n-1][n-1]; } ( https://godbolt.org/z/DV9c-C ) Btw, that definition was obsolescent in C89 too.
Well, yes. But putting the array argument(s) first is the more natural order, in my opinion. And it is surely odd that only one order is allowed in this context, when otherwise C is happy with changing the order of parameters to be whatever you like.
Plus, of course, there may be existing code using such functions, with parameters in the order that would become impossible if this syntax were disallowed.