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

211–220 of 978 posts

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

#211

Post by pascal_cuoq »

rvp-x wrote: post #97

A lot of you seem to be working on commercial solutions to C's insecurity. Does this feel like a conflict of interest to you?

I have been told in this very AMA that I lacked enthusiasm about C (and the gratuitous insecurity of the language when we know that a well-designed type system and a few runtime checks solve the problem entirely is indeed the reason for my perceived lack of enthusiasm): https://news.ycombinator.com/item?id=22865912

I hope that this perceived lack of enthusiasm means I am handling the conflict of interest honorably.

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

#212

Post by Someone »

AvImd wrote: post #95

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.

  int i;
  […]
  i += 1;
potentially is undefined behavior; i could overflow.

Compilers nowadays are fairly good at warning about definite undefined behavior.

I don’t think anybody would be happy with a compiler that aborted on all potential undefined behavior. That would (almost) be equivalent to banning the use of all signed ints.

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

#213

Post by emilfihlman »

rseacord wrote: post #71
emilfihlman wrote: post #36

Thank you for taking time to take questions! Have you ever considered or will you consider deprecating char, int, long, (s)size_t, float, double and etc in favour of specific length types? Will you ever add / have you considered adding [su]\d+ and f\d+ as synonyms for those mentioned stdint.h? Since char is signed on most platforms, arm eabi being an exception and even there it's really just a matter of compile time…

I don't think we'll ever deprecate char, int, long, float, double, or size_t. ssize_t is not part of the C Standard, and hopefully never will be as it is a bit of an abomination. The main driver behind the evolution of the C Standard is not to break existing code written in C, because the world largely runs on C programs. C does provide fixed width types like uint8_t, uint16_t, uint32_t, and uint64_t. These are optio…

>The main driver behind the evolution of the C Standard is not to break existing code written in C, because the world largely runs on C programs.

If not deprecate, then at least make fixed width types as equivalent members to them, ie all char based apis should accept s8 (typedef signed char s8) and all int based apis should accept s32.

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

#215

Post by eqvinox »

rseacord wrote: post #181
rwmj wrote: post #123

Not a question, a request: Please make __attribute__((cleanup)) or the equivalent feature part of the next C standard. It's used by a lot of current software in Linux, notably systemd and glib2. It solves a major headache with C error handling elegantly. Most compilers already support it internally (since it's required by C++). It has predictable effects, and no impact on performance when not used. It cannot be imple…

My idea was to add something like the GoLang defer statement to C (as a function with some special compiler magic). The following is an example of how such a function could be used to cleanup allocated resources regardless of how a function returned: int do_something(void) { FILE *file1, *file2; object_t *obj; file1 = fopen("a_file", "w"); if (file1 == NULL) { return -1; } defer(fclose, file1); file2 = fopen("another…

Cleanup on function return is not enough, it needs to be scope exit. We're using this for privilege raising/dropping (example posted above) and also mutex acquisition/release. Both of these really "want" it on the scope level.

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

#216

Post by cesarb »

pascal_cuoq wrote: post #19
papermachete wrote: post #11

How and why will C combat Rust?

In my opinion, the two languages are going to co-exist for a long time. C has billions of lines of legacy software written in it… In recent news, COBOL developers were sought after in order to update existing COBOL software, so the same thing will happen with C, perhaps to the end of humanity (I have become pessimistic as to humanity's future). There are pieces of software that should be given priority for a rewrite…

> In my opinion, the two languages are going to co-exist for a long time.

It goes deeper than that, in a couple of places Rust depends on the C standard: the fixed-layout `#[repr(C)]` structs (without that attribute, the compiler is free to reorder the struct fields; with that attribute, it's laid out the way C would do it), and the `extern "C"` function call ABI. The way to call any other language from Rust, or Rust from any other language, is to go through `extern "C"` functions passing `#[repr(C)]` structs. So even if the C language dies one day, parts of it will live in Rust forever (or as long as the Rust language lives).

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

#217

Post by buckminster »

gwd wrote: post #162
cataphract wrote: post #109

Earlier quoted context omitted.

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…

So in a corner case where you have a loop that iterates over all integer values (when does this ever happen?) you can optimize your loop. As a consequence, signed integer arithmetic is very difficult to write while avoiding UB, even for skilled practitioners. Do you think that's a useful trade-off, and do you think anything can be done for those of us who think it's not?

N is a variable. It might be INT_MAX so the compiler cannot optimise the loop for any value of N. Unless you make this UB.

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

#218

Post by andrepd »

gwd wrote: post #162
cataphract wrote: post #109

Earlier quoted context omitted.

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…

So in a corner case where you have a loop that iterates over all integer values (when does this ever happen?) you can optimize your loop. As a consequence, signed integer arithmetic is very difficult to write while avoiding UB, even for skilled practitioners. Do you think that's a useful trade-off, and do you think anything can be done for those of us who think it's not?

No, it's exactly the opposite. Without UB the compiler must assume that the corner case may arise at any time. Knowing it is UB we can assert `n+1 > n`, which without UB would be true for all `n` except INT_MAX. Standardising wrap-on-overflow would mean you can now handle that corner case safely, at the cost of missed optimisations on everything else.

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

#219

Post by david2ndaccount »

pascal_cuoq wrote: post #153
parenthesis wrote: post #103

Could we have variadic macros with zero arguments in the standard? I'm not using any compiler that doesn't allow it.

The C standard description does not allow a function that does not have at least one normal argument before the variadic arguments. Conceptually, something must indicate to the function how many arguments it is supposed to request next, and with what types. Yes, you could write a function where this information is passed through a static-lifetime variable, but in practice the first mandatory argument is almost always…

You’re replying to a comment about macros, not about functions.

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

#220

Post by RandNOx »

- Which differences between the C abstract machine and actual modern CPUs/hardware have proven most difficult to deal with in the language?

- Are you planning any addition regarding modeling of how modern CPUs work (e.g. pipelines, branches, speculative execution, cache lines, etc)?

PS: Thank you for doing this!

Post reply on HN