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

741–750 of 978 posts

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

#741

Post by namibj »

tropo wrote: post #703
rseacord wrote: post #119

Earlier quoted context omitted.

I think we are always looking at ways to "clean up C" but that this has to be done very carefully not to break existing code. For example, the committee recently voted to remove support for function definitions with identifier lists from C2x http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf At least one vendor was not very happy with this decision. Undefined behaviors tend to be undefined for a reason and sho…

C has strayed very far from the original intent because compiler authors prioritized benchmark results at the expense of real-world use cases. This bad trend needs to be reversed. Consider signed integer overflow. The intent wasn't that the compiler could generate nonsense code if the programmer overflowed an integer. The intent was the the programmer could determine what would happen by reading the hardware manual.…

There are some add-with-saturation opcodes in 8bit-element-size SIMD ISAs, I think that includes x86_64, some recent Nvidia GPUs, and the Raspberry Pi 1's VideoCore IV's strange 2D-register-file vector unit made for implementing stuff like VP8/H.264 on it. They are afaik always opt-in, though.

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

#742

Post by spc476 »

clarry wrote: post #684
quelsolaar wrote: post #666

Earlier quoted context omitted.

This attitude is terrible! Its an attitude that says that unless you know exactly every pit fall in the language by heart you have no place writing code. I guess you dont use a debugger either because you never write bugs right? And you think that every software that helps the user is for noobs right? There is an endless list of bugs that have been produced by very competent C programmers, because the compiler has si…

Huh? I just want performant code. That's why I write C, and that's why I use an optimizing compiler, and that's why I ask my compiler to optimize. I also want to write code that is reasonably generic. Thus, it will have checks and branches that cover important corner cases; they are required for completeness and correctness. But very often, all of these checks turn out to be redundant in a specific context, and an op…

Why can't the following be a warning?

    int foo(bar *x)
    {
      x->blah = 0;
      if (x == NULL) ... 
      ...
    }
And produce something like "NULL check removed---pointer used before check"?

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

#743

Post by saagarjha »

_kst_ wrote: post #516
professoretc wrote: post #369

Earlier quoted context omitted.

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.

No, uintptr_t is an integer type to which any object pointer type can be converted without loss of information. (Strictly speaking, the guarantee is for conversion to and from void*.) And if an implementation doesn't have a sufficiently wide integer type, it won't define uintptr_t. (Likewise for intptr_t the signed equivalent.) There's no guarantee that a function pointer type can be converted to uintptr_t without lo…

Note that POSIX requires that object pointers and function pointers are the same for dlsym.

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

#744

Post by asveikau »

saagarjha wrote: post #728
asveikau wrote: post #489

Earlier quoted context omitted.

> in a lot of cases, it will be harmless; and in the worst case it will crash with a segfault. I am not sure if a segfault is always the worst case. It could be by some coincidence that array[i] contains some confidential information [maybe part of a private key? 32 bits of the user's password?] and you've now written it to a log file. I know it's hard to imagine a mis-read of ~32 bits would have bad consequences of…

Misreads of much less than that have been exploitable in the past.

Depends a lot on the specifics. For example heartbleed was a misread that led to the buffer being sent on the socket. And I think it was more than 32 bits. 32 bits of garbage into a log file that needs privileges to read sounds a tad less scary, but like I say, not out of the question to be harmful.

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

#745

Post by userbinator »

cataphract wrote: post #109
beefhash wrote: post #33

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

Signed overflow being undefined behavior allows optimizations that wouldn't otherwise be possible Quoting http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be…

I've always thought that assuming such things should be wrong, because if you were writing the Asm manually, you would certainly think about it and NOT optimise unless you had a very good reason why it won't overflow. Likewise, I think that unless the compiler can prove that it, it should, like the sane human, refrain from making the assumption.

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

#746

Post by saagarjha »

klodolph wrote: post #485
iainmerrick wrote: post #443

Earlier quoted context omitted.

the compiler is allowed to assume the loop terminates precisely because signed overflow is undefined. Just to be sure I understand the fine details of this -- what would the impact be if the compiler assumed (correctly) that the loop might not terminate? What optimization would that prevent?

> …what would the impact be if the compiler assumed (correctly) that the loop might not terminate? Loaded question—the compiler is absolutely correct here. There are two viewpoints where the compiler is correct. First, from the C standard perspective, the compiler implements the standard correctly. Second, if we have a real human look at this code and interpret the programmer’s “intent”, it is most reasonable to assu…

You shouldn't even need compiler builtins, just perform undefined behavior on a branch:

  if ((uintptr_t)ptr & alignment) {
      char *p = NULL;
      printf("%c\n", *p);
  }

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

#747

Post by saagarjha »

rseacord wrote: post #91
beefhash wrote: post #33

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

Maybe someone else can respond to this as well, but I feel like the primary reason signed overflow is still undefined behavior is because so many optimizations depend upon the undefined nature of signed integer overflow. My advice has always been to use unsigned integer types when possible. Personally, I would like to get rid of many of the trap representations (e.g., for integers) because there is no existing hardwa…

> My advice has always been to use unsigned integer types when possible.

Unsigned types have their own issues, though: they overflow at "small" values like -1, which means that doing things like correctly looping "backwards" over an array with an unsigned index is non-trivial.

> On the other hand, I just wrote a proposal to WG14 to make zero-byte reallocations undefined behavior that was unanimously accepted for C2x.

You're saying that realloc(foo, 0) will no longer free the pointer?

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

#749

Post by rs23296008n1 »

Modern C language features:

- Why no sized text strings?

- Why is there no hash data type?

- Where's the linked list?

- Why no package management as part of ecosystem?

What is the modern rationale?

Caveats:

- I'm not implying any need for object-orientation (OOP)

- I'm fully aware I can write these myself and can access third party libraries that have each laboriously implemented their own versions.

- I'm interested in why these are not native C constructs in 2020. I appreciate why not in 1980.

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

#750

Post by saagarjha »

hyc_symas wrote: post #531

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…

I recently looked at a number of string copying functions, as well as came up with an API a bit similar to yours: https://saagarjha.com/blog/2020/04/12/designing-a-better-str... (mine indicates overflow more clearly). memccpy, which is coming in C2X, makes designing these kinds of things finally possible.
Post reply on HN