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

141–150 of 978 posts

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

#141

Post by rseacord »

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?

Good question, but not at all! I've been working as hard as I can for the past 15 years to improve C Language security as have other security-minded members of the committee. Generally speaking, we are in the minority as performance is still the major driver for the language. Any security solution that introduces > 5% overhead, for example, is a nonstarter. I think we all understand that are jobs are completely safe no matter what security improvements we can get adopted.

The committee works a lot lobbyist. A minority of people with a large financial interest in the technology (such as compiler writers) have undue influence because they participate in the process. I always encourage C language users to take a more active role, but they usually don't. Cisco is an example of user community that actively takes part in C Standardization.

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

#143

Post by pascal_cuoq »

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.

It sounds like the __attribute__((cleanup(…))) already offered by GCC is similar to this. I probably won't have time to investigate the differences while the AMA is ongoing though.

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

#144

Post by DougGwyn »

msebor wrote: post #118
nicoburns wrote: post #81

Are there any plans to "clean up C"? A lot of effort has been put into alternative languages, which are great, but there is still a lot of momentum with C, and it seems that a lot of improvements that could be done in a backwards compatible way and without introducing much in the way of complexity. For example: - Locking down some categories of "undefined behaviour" to be "implementation defined" instead. - Proper ar…

There are "projects" underway to clean up the spec where it's viewed as either buggy, inconsistent, or underspecified. The atomics and threads sections are a coupled of example. There are efforts to define the behavior in cases where implementations have converged or died out (e.g., twos complement, shifting into the sign bit). There have been no proposals to add new array types and it doesn't seem likely at the core…

Actually there was no need to disenfranchise non-twos-complement architectures. Now that SIMH has a CDC-1700 emulation, I had planned on producing a C system for it as an example for students who have never seen such a model.

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

#146

Post by colanderman »

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?

Beside optimization (as others have pointed out), disallowing wrapping of signed values has the important safety benefit that it permits run-time (and compile-time) detection of arithmetic overflow (e.g. via -fsanitize=signed-integer-overflow). If signed arithmetic were defined to wrap, you could not enable such checks without potentially breaking existing correct code.

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

#147

Post by rseacord »

jpfr wrote: post #21

C11 has seen new features, such as Generic Selection. Is the current language standardization converging (just adding clarifications, removing the surface for undefined behavior, etc.) or is C still growing with new features? In other words, will the C standard be effectively “done” at some time in the future?

A full list of proposals to WG14 can be found here:

http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log...

These papers are usually quite interesting.

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

#149

Post by wyldfire »

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?

Could we instead just have standard-defined integer types which saturate or trap on overflow?

Sometimes you're writing code where it really, really matters and you're more than willing to spend the extra cycles for every add/mul/etc. Having these new types as a portable idiom would help.

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

#150

Post by eqvinox »

AaronBallman wrote: post #139
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…

Funny you should mention that, as that feature has come up recently in mailing list discussions. We have not seen an actual proposal for adopting it yet, but features similar semantics are being discussed as a possible idea (no promises). FWIW, I don't think it would wind up being spelled with attribute syntax because we would likely want programmers to have a guarantee that the cleanup will happen (and attributes ca…

Hopefully it'd at least be syntactically similar, so we can have an

  #ifdef __STDC_CLEANUP__
  #define my_cleanup(func) stdc_cleanup(func)
  #else
  #define my_cleanup(func) __attribute__((cleanup(func)))
  #endif
i.e. it would require that it at least goes in the same places as an attribute.
Post reply on HN