Live data from Hacker News

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

news.ycombinator.com

451–460 of 978 posts

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

#451
post #352

When deciding on the behavior of some operation that maps to hardware [1], how do you weight the existing hardware behaviors? For example, if all past, current and contemplated hardware behaves in the same way, I assume that the standard will simply enshrine this behavior. However, what if 99% of hardware behaves one way and 1% another? Do you set the behavior to "undefined" to accommodate the 1%? At what point to yo…

A good example might be 1's complement signed integers. They were dead weight in the standard for a long time.

Yes, but that is a slightly different question: how long you do you keep something in the standard after all the relevant hardware has disappeared, e.g,. is there a framework for periodically re-evaluating decisions in light of the changing hardware landscape.

My question was more about when behavior is being defined for the first time, which admittedly doesn't happen that often (but it could apply e.g., when thing fixed-width integer types, uintX_t and friends were introduced).

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

#452

Earlier quoted context omitted.

It would presumably involve a new type that didn't exist in the current ABI. Those pointers would stay the same, and the new (twice as big) pointers would be used for the array feature.

The point of uintptr_t is that it's an integer type to which any pointer type can be cast. If you introduce a new class of pointers which are not compatible with uintptr_t, then suddenly you have pointers which are not pointers.

You would be shocked by this language called C++ which is highly compatible with C and has "pointer to member" types that don't fit into a uintptr_t.

(Spoiler: no, there is no uintptr2_t).

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

#454

A few years ago I came across this article Pointers Are More Abstract Than You Might Expect In C [1]. I followed the article which attempted to interpret the C standard and come to a conclusion. The conclusion is: > The takeaway message is that pointer arithmetic is only defined for pointers pointing into array objects or one past the last element. Comparing pointers for equality is defined if both pointers are deriv…

The only thing that is not defined is comparing a pointer one-past-the-end to a pointer to the very beginning of a toplevel object. Apart from this rule, pointers of course do not need to be derived from the same object in order to be compared with == and !=.

&a + 1 == &b is unspecified: it may produce 0 or 1, and it may not produce the same result if you evaluate it several times.

Similarly, if both the char pointers p and q were obtained with malloc(10), after they have been tested for NULL, all these operations are valid:

  p == q (false)
  p + 1 == q (false)
  p + 1 == q + 1 (false)
  p + 10 == q + 1 (false)
Only p+10 == q and p == q+10 are unspecified (of the comparisons that can be built without invoking UB during the pointer arithmetic itself).

I have no idea what led that person to (apparently) write that &a==&b is undefined. This is plain wrong. I do not see any ambiguity in the relevant clause (https://port70.net/~nsz/c/c11/n1570.html#6.5.9p6 ). Yes, the standard is in English and natural languages are ambiguous, but you might as well claim that a+b is undefined because the standard does not define what the word “sum” means (https://port70.net/~nsz/c/c11/n1570.html#6.5.6p5 ).

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

#455
post #306

Is the committee planning on working on the preprocessor? I don't see any reason for not boosting it. It's time for C to have real meta-programming. Would be nice to have local macros that are scoped. On another note: - Official support for __attribute__ - void pointers should offset the same size as char pointers. - typeof (can't stress this one enough) - __VA_OPT__ - inline assembly - range designated initializer f…

+1 for Modern Metaprogramming.

I know some people are against metaprogramming because they believe the abstractions hide the intrinsic of how the underlying code will execute, but I would love to write substantial tests in C without relying on FFI to Python or C++ to perform property-based testing, complex fuzzing, and whatever. I feel metaprogramming would be a huge boon for C tooling and developer productivity.

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

#456

Earlier quoted context omitted.

This is an entire language extension, as you note. The last time various people interested in this were in the same room (it was in January 2020 in a workgroup called HACS), what emerged was that the Rust people would try to add the “secret” keyword to the language first, since their language is still more agile than C, while the LLVM people would prepare LLVM for the arrival of at least one front-end that understand…

Also worth noting that a language extension may not be sufficient for all cases. E.g. the OS stores register state on a context switch; do you also need a flag for the system to zero any memory used for this purpose following the state restore, or is it OK to trust that it won’t leak through some mechanism? For some applications, there may be contractual or regulatory requirements to have an erasing mechanism for cop…

I want to use this in the OS kernel too. ;-)

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

#457
post #327
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…

> But the compiler is like "hey! you used the result of this function as an index for this array! i must be in the range [0, 10)! I can use that information!"

As a developer who has seen lots of developers (including himself) make really dumb mistakes, this seems like a very strange statement.

Imagine if you hired a security guard to stand outside your house. One day, he sees you leave the house and forget to lock the door. So he reasons, "Oh, nothing important inside the house today -- guess I can take the day off", and walks off. That's what a lot of these "I can infer X must be true" reasonings sounds like to me: they assume that developers don't make mistakes; and that all unwanted behavior is exactly the same.

So suppose we have code that does this:

  int array[10];
  int i = some_function();

  /* Lots of stuff */
  if ( i > 10 ) {
    return -EINVAL;
  }

  array[i] = newval;
And then someone decides to add some optional debug logging, and forgets that `i` hasn't been sanitized yet:

  int array[10];
  int i = some_function();

  logf("old value: %d\n", array[i]);

  /* Lots of stuff */

  if ( i > 10 ) {
    return -EINVAL;
  }

  array[i] = newval;
Now reading `array[i]` if `i` > 10 is certainly UB; but in a lot of cases, it will be harmless; and in the worst case it will crash with a segfault.

But suppose a clever compiler says, "We've accessed array[i], so I can infer that i read into an out-of-bounds write, which has changed worst-case a DoS into a privilege escalation!

I don't know whether anything like this has ever happened, but 1) it's certainly the kind of thing allowed by the spec, 2) it makes C a much more dangerous language to deal with.

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

#459

Earlier quoted context omitted.

Many uses of strchr do write via a pointer derived from a non-const declaration. When we introduced const qualifier it was noted that they were actually declaring read-only access, not unchangeability. The alternative was tried experimentally and the consequent "const poisoning" got in the way.

I believe C is doing the right thing. Const as immutability is a kludge to force the language to operate at the level of data structure/API design, something that it cannot do properly.

Have you ever used a high-level statically-typed language, e.g. haskell?

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

#460
post #440

How close C Standard Committee works with Linux Kernel Developers? Is Linux Kernel development influence on C standard?

There's not an official collaboration between the committee and the kernel developers (that I'm aware of), but we do have people on the committee who need to support Linux kernel development (such as GCC maintainers), so there is some level of indirect influence there.
Post reply on HN