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

101–110 of 978 posts

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

#101

Post by bokwoon »

rseacord wrote: post #10

So what do people think about having a feature in the C language akin to the defer statement in GoLang? The GoLang defer statement defers the execution of a function until the surrounding function returns. The deferred call's arguments are evaluated immediately, but the function call is not executed until the surrounding function returns. It looks like an interesting mechanism for cleaning up resources.

How about deferring until the surrounding block scope ends? In Go you can get around the limitation of defer only executing at the end of a function by wrapping any arbitrary section of code inside an immediately executed anonymous function. But in C I'm not sure that's possible so maybe one could declare a new block scope instead to control when defer kicks in.

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

#102

Post by eqvinox »

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)

I haven't read most of that rant, but a thread-local setlocale() would be a godsend. Not sure if that's ISO C or POSIX though.

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

#105

Post by pascal_cuoq »

Lucasoato wrote: post #77

Is there any new programming language that you particularly love? Do you like the way programming is evolving?

As a member of the development team for a C static analyzer, I use OCaml, which is also my favorite programming language, but that is because I'm from the generation in which it was the new thing (I learnt it when it had the same level of maturity as Rust, at a time when Rust didn't exist). It helps that it's perfect for writing compilers and static analyzers.

There are a lot of problems that seem a good match for Rust, and Rust is first in my list of programming languages I will never find the time to learn but wish I could.

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

#106

Post by klodolph »

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?

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 overflow defined behavior will impact the performance of numerics libraries that are currently written in C.

From my personal experience, having numbers wrap around is not necessarily “better” than having the behavior undefined, and I’ve had to chase down all sorts of bugs with wraparound in the past. What I’d personally like is four different ways to use integers: wrap on overflow, undefined overflow, error on overflow, and saturating arithmetic. They all have their places and it’s unfortunate that it’s not really explicit which one you are using at a given site.

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

#107

Post by jfkebwjsbx »

OnACoffeeBreak wrote: post #89
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)

I know that we're not voting, but I miss a binary literal very much. I would also like a literal digit separator to improve readability. Verilog Hardware Description Language does that with an underscore [1]. For example, 0xad_beef to improve readability of a hex literal, and 0b011_1010 to improve readability of a binary literal. 1: http://verilog.renerta.com/mobile/source/vrg00020.htm

If they pick this up, they will likely use C++'s syntax/rules.

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

#108

Post by AaronBallman »

emilfihlman wrote: post #98
AaronBallman wrote: post #72

Earlier quoted context omitted.

> 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] an…

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

That's my personal preference as well. Using the PRI macros always makes me feel sad.

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

Ah, no, I don't recall any proposals along those lines. It's an interesting idea, and I'd be curious what the runtime performance characteristics would be vs what kind of new coding patterns would emerge that you couldn't do previously though!

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

#109

Post by cataphract »

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 undefined) allows optimizing "X*2/2" to "X". While these may seem trivial, these sorts of things are commonly exposed by inlining and macro expansion. A more important optimization that this allows is for "> for (i = 0; i > In this loop, the compiler can assume that the loop will iterate exactly N+1 times if "i" is undefined on overflow, which allows a broad range of loop optimizations to kick in. On the other hand, if the variable is defined to wrap around on overflow, then the compiler must assume that the loop is possibly infinite (which happens if N is INT_MAX) - which then disables these important loop optimizations. This particularly affects 64-bit platforms since so much code uses "int" as induction variables.

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

#110

Post by stephencanon »

rini17 wrote: post #64
stephencanon wrote: post #59

Earlier quoted context omitted.

> (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…

And are there standard primitives to do this correctly (signed-unsigned-signed conversion) that never invoke undefined behavior?

Signed to unsigned conversion is fully defined (and does the two's complement thing):

> Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type (6.3.1.3 Signed and unsigned integers)

Unsigned to signed is the hard direction. If the result would be positive (i.e. in range for the signed type), then it just works, but if it would be negative, the result is implementation-defined (but note: not undefined). You can further work around this with various constructs that are ugly and verbose, but fully defined and compilers are able to optimize away. For example, `x <= INT_MAX ? (int)x : (int)(x + INT_MIN) + INT_MIN` works if int has a twos-complement representation (finally guaranteed in C2x, and already guaranteed well before then for the intN_t types), and is optimized away entirely by most compilers.

Post reply on HN