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

91–100 of 978 posts

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

#91

Post by rseacord »

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 hardware in many cases that supports them and it gives implementers the idea that uninitialized reads are undefined behavior.

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

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

#92

Post by ux »

pascal_cuoq wrote: post #84
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)

Many C compilers offer, as an extension, the very binary constant notation that you miss, as anyone who has worked on the front-end of a C static analyzer would tell you.

Yes I'm aware. But we can agree it would be welcome in the standard, isn't it?

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

#93

Post by jimktrains2 »

stephencanon wrote: post #59
rbultje wrote: post #38

I'd love your opinion on the abundance of "undefined behaviour" (as opposed to implementation-defined, or some new incantation such as "unknown result in variable but system is safe") for relatively trivial things such as signed (but not unsigned) integer overflows. I've heard that this is to allow for non-twos-complement implementations. However, in practice, you notice that most people use ugly workarounds which le…

> (because of e.g. casting to unsigned and allowing the same overflow to happen anyway) only work correctly on twos-complement anyway Unsigned arithmetic never overflows, and guarantees two's-complement behavior, because unsigned arithmetic is always carried out modulo 2^n: > A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer typ…

Interesting. I guess most/many arch's overflow flag is set when the sign bit changes and the carry flag when the result rollsover the word size.

I think most people colloquially call going A + 1 = B where B < A an overflow. Interesting. I knew they're different things, but never really thought about my word choice.

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

#94

Post by msebor »

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?

Some instances of undefined behavior at translation time can effectively be avoided in practice by tightening up requirements on implementations to diagnose them. But strictly speaking, because the standard allows compilers to continue to chug along even after an error and emit object code with arbitrary semantics, turning even such straightforward instances into constraint violations (i.e., diagnosable errors) doesn't prevent UB.

It might seem like defining the semantics for signed overflow would be helpful but it turns out it's not, either from a security view or for efficiency. In general, defining the behavior in cases that commonly harbor bugs is not necessarily a good way to fix them.

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

#95

Post by AvImd »

Is there a possibility there will be introduced a new rule saying "if the compiler detects an UB it should abort the compilation instead of breaking the code in the most incomprehensible way possible"?

Right now it's just scary to start a new project in C. It would be really great if there was more emphasis on correctness of the produced code instead of the insane optimizations.

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

#96

Post by NickDunn »

orsenthil wrote: post #68

Why is still the learning curve for C so high? * Why can't the learning curve be solved using tools? * Why don't we actively promote more higher level languages which are implemented in C (by fewer people)?

I think that C provides fewer layers of abstraction than other languages. This requires the programmer to deal with memory management, treat strings as an array of characters, and other things that the majority of high-level languages conceptualise, so that the human mind deals with it more easily. This provides advantages and disadvantages, as it requires more thought and understanding to write the code but also allows the use of low-level features. The lack of tools to solve any learning issues is probably down to the programmer needing the right conceptual understanding and the requirements placed on anyone using the various features of the language.

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

#98

Post by emilfihlman »

AaronBallman wrote: post #72
emilfihlman wrote: post #50

Will you ever add / have you considered adding sane formatting options for fixed length variables in printf? Say %u32 or %s64 ? Have you considered adding access to structure members by index or by string name? Have you considered dynamic structures?

> Will you ever add / have you considered adding sane formatting options for fixed length variables in printf? Say %u32 or %s64 ? I'm not certain about the historical answer to this, but I do know that we're currently considering a proposal to introduce an exact bit-width integer type '_ExtInt(N)' to the language, and how to handle format specifiers for it is part of those discussions, so we are considering some chan…

>and how to handle format specifiers for it is part of those discussions, so we are considering some changes in this area.

Please, please, please pick short and descriptive format specifiers, like %[suf]\d+, ie

  s64 v=somenumber;
  printf("%s64\n", v);
_ExtInt(N) and PRIx64 etc look absolutely horrid. u?int\d+_t are also really bad, it would be great to have just [suf]\d+ as types, where \d+ is 8, 16, 32, 64 for [us] and 32 and 64 for f.

>what do you have in mind there?

Say like VLAs but structures with members that are dynamically defined and used.

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

#99

Post by AaronBallman »

knz42 wrote: post #28

What is the story behind the removal of VLAs from C99 in later revisions?

VLAs are still present in C17 and have not been removed. They are, however, an optional feature with a truly weird (IMHO) feature testing macro. If '__STDC_NO_VLA__' is defined to 1, then the implementation does not support VLAs.

IIRC, this macro was added to C11 along with a batch of other "these are optional" macros for atomics, complex, threads, etc. However, I don't recall whether C99 adopted the features as optional features and missed the feature testing macro, or if they were required features in C99 that we made optional in C11.

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

#100

Post by rmind »

emilfihlman wrote: post #50

Will you ever add / have you considered adding sane formatting options for fixed length variables in printf? Say %u32 or %s64 ? Have you considered adding access to structure members by index or by string name? Have you considered dynamic structures?

Just FYI -- there are macros for the fixed-length types, e.g.:

    printf("U32: %" PRIu23 ", U64: " PRId64, (uint32_t)1, (int64_t)2);
Perhaps not as handy as %u32 or %s64, but it's here.
Post reply on HN