Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

391–400 of 978 posts

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

#391

Post by pascal_cuoq »

Tronic2 wrote: post #80

Why is the struct tm* returned by localtime() not thread-local like errno and other similar variables are (at least in implementations)? Do you have any plans to improve calendar support for practical uses?

Both question would get better answers if they were asked to a panel of experts on POSIX (which could including members of the POSIX standardization committee).

For the first one, I can attempt a guess: maybe it was feared that making the result of localtime thread-locale would break some programs? You could build such a program on purpose, although I am not clear how frequently one would write one by accident.

Anyway, localtime_r is the function that one should use if one is concerned by thread-safety. A more likely answer is that no Unix implementation bothered to fix localtime because the proper fix was for programs to call localtime_r.

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

#392

Post by ori_b »

nicoburns wrote: post #81

Are there any plans to "clean up C"? A lot of effort has been put into alternative languages, which are great, but there is still a lot of momentum with C, and it seems that a lot of improvements that could be done in a backwards compatible way and without introducing much in the way of complexity. For example: - Locking down some categories of "undefined behaviour" to be "implementation defined" instead. - Proper ar…

> - Some kind of module system, that allows code to be imported with the possibility of name collisions.

That doesn't particularly need modules -- just some form of

     namespace foo {
     }

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

#394

Post by coliveira »

alerighi wrote: post #265
klodolph wrote: post #106

Earlier quoted context omitted.

Just going to inject that this impacts a bunch of random optimizations and benchmarks. Just to fabricate an example: for (int i = 0; i Reasonably common idea but the compiler is allowed to assume the loop terminates precisely because signed overflow is undefined. I’m not trying to argue that signed overflow is the right tool for the job here for expressing ideas like “this loop will terminate”, but making signed over…

The compiler assumes that the loop will alwasy terminate and that assumption is wrong, because in reality there is the possibility that the loop will not terminate, since the hardware WILL overflow. So it's not the best solution. If we want to make this behaviour for optimizations (that are to me not worthed, giving the risk of potentially critical bugs) we must make that behavior explicit, not implicit: thus is the…

> I guarantee you that this operation will never overflow, if it does it's my fault.

This is exactly what every C programmer does, all the time.

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

#397

Post by msebor »

Spivak wrote: post #327
3JPLW wrote: post #223

Earlier quoted context omitted.

Does it concern you how aggressively compiler teams are exploiting UB?

You do have to understand that compiler teams aren't saying something like "this triggers UB, quick just replace it with noop." It's just something that naturally happens when you need to reason about code. For example, consider a very simple statement. let array[10]; let i = some_function(); print(array[i]); The function might not even be known to the compiler at compilation time if it was from a DLL or something. B…

This is a good example. Let me flesh it out a bit more to illustrate a specific instance of this problem:

  int a[2][2];
  int f (int i, int j)
   {
       int t = a[1][j];
       a[0][i] = 0;          // cannot change a[1]
       return a[1][j] - t;   // can be folded to zero
   }
The language says that elements of the matrix a must only be accessed by indices that are valid for each bound, so compilers can and some do optimize code based on that requirement (see https://godbolt.org/z/spSF8e).

But when a program breaks that requirement (say, by calling f(2, 0)) the function will likely return an unexpected value.

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

#398

Post by ori_b »

msebor wrote: post #370
3JPLW wrote: post #223

Earlier quoted context omitted.

Does it concern you how aggressively compiler teams are exploiting UB?

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…

There are rules and requirements documented in the spec, and there are de-facto rules and requirements that programs expect. Not only that, but when they do exploit these rules, often the code generated is obviously incorrect, and could have been flagged at compile time.

Right now, it seems like compiler vendors are playing a game of chicken with their users.

Post reply on HN