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

331–340 of 978 posts

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

#331

Post by AaronBallman »

lemaudit wrote: post #238

Hi, Do you think Annex K of C11 will be widely adopted by programmers or unused? Why aren't people adopting it? Do you see the use of any analysis tools that are particularly effective for finding memory safety issues? C++ added in smart pointers to its specification. Are there any plans to do something similar in future C specifications? Thanks!

> Do you think Annex K of C11 will be widely adopted by programmers or unused? Why aren't people adopting it?

So far, it's not been widely adopted. Part of the issue is that there are specification issues relating to threads and the constraint handlers, and part of the issue is that popular libc implementations have actively resisted implementing the annex.

That said, I field questions about Annex K on a regular basis and there are a few implementations in the wild, so there is user interest in the functionality.

> Do you see the use of any analysis tools that are particularly effective for finding memory safety issues?

I think CodeSonar does a great job at finding memory safety issues, but I work for the company that makes this tool.

I've also had good luck with the memory and address sanitizers (https://github.com/google/sanitizers) and tools like valgrind.

> C++ added in smart pointers to its specification. Are there any plans to do something similar in future C specifications?

We currently don't have any proposals for adding smart pointers to C. Given that C does not have constructors or destructors, we would have to devise some new mechanism to implement or replace RAII in C, which would be one major hurdle to overcome for smart pointers.

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

#332

Post by cesarb »

loeg wrote: post #311
cesarb wrote: post #134

Earlier quoted context omitted.

> Proper array support (which passes around the length along with the data pointer). I second this one. One of the best things from Rust is its "fat pointers", which combine a (pointer, length) or a (pointer, vtable) pair as a single unit. When you pass an array or string slice to a function, under the covers the Rust compiler passes a pair of arguments, but to the programmer they act as if they were a single thing (…

Fat pointers in C would involve an ABI break for existing code, in that uintptr_t and uintmax_t would probably need to double in size.

Existing code would be using normal pointers, not fat pointers, so there would be no ABI break. New code using fat pointers would know that they fit into a pair of uintptr_t, so the size of uintptr_t would not need to change either.

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

#333

Post by hsivonen »

What’s the current committee thinking on providing locale-independent conversions from potentially-invalid UTF-8 to valid UTF-8, from potentially-invalid UTF-8 to valid UTF-16, and from potentially-invalid UTF-16 to valid UTF-8 (i.e. replacing ill-formed sequences with yhe REPLACEMENT CHARACTER)?

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

#334

Post by artursapek »

rseacord wrote: post #251
artursapek wrote: post #235

Earlier quoted context omitted.

Why won't you ever find time? It should only take a good 20 hours of reading and playing with code before you start to grok it.

I spent the early part of my career bragging about how many programming languages I knew, and the later part of my career complaining about how I don't know any of them well enough.

I certainly wouldn't go for quantity there, but if you really want to learn Rust you should. It brings some groundbreaking new ideas to programming and is more than "just another language".

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

#335

Post by msebor »

emilfihlman wrote: post #294
msebor wrote: post #283

Earlier quoted context omitted.

Yes, it's undefined. It involves a read of an uninitialized local variable. Except for the special case of unsigned char, any uninitialized read is undefined.

>Except for the special case of unsigned char, any uninitialized read is undefined. Could you expand on this?

An object of any type, initialized or not, can be read by an lvalue of unsigned char (or any character type). That lets functions like memcpy (either the standard one or a hand-rolled loop) copy arbitrary chunks of memory.

There's some debate about the effects of reading an uninitialized local variable of unsigned char (like whether the same value must be read each time, or whether it's okay for each read to yield a different value).

This special exemption doesn't extend to any other types, regardless of whether or not they have padding bits or trap representations that could cause the read to trap. Few types do, yet the behavior of uninitialized reads in existing implementations is demonstrably undefined (inconsistent or contradictory to invariants expressed in the code of a test case), so any subtleties one might derive from the text of the standard must be viewed in that light.

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

#336

Post by thayne »

andrepd wrote: post #218
gwd wrote: post #162

Earlier quoted context omitted.

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.

Have you considered adding intrinsic functions for arithmetic operations that _do_ have defined behavior on overflow. Such as the overflowing_* functions in rust?

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

#337

Post by Jahak »

pascal_cuoq wrote: post #186
Jahak wrote: post #154

Tell me where I can get the C89 standard for free (pdf or other formats)

The last time I needed it, archive.org had a link to a PDF of it. I couldn't find that again in one minutes, but here is the text version: http://web.archive.org/web/20030222051144/http://home.earthl...

Thanks

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

#338

Post by loeg »

rwmj wrote: post #171
AaronBallman wrote: post #139

Earlier quoted context omitted.

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…

I believe the last proposal was in 2008 (ignore the try..finally stuff here): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1298.pdf So I guess it needs someone to take that and update it, also to pull up a full list of current Linux software which is using this feature (which as I say these days is a surprising amount).

We use it extensively in our proprietary codebases as well, FWIW. Not real open data for me to point to, but: a few million lines of C, and a handful of billion USD in revenue. If that helps weigh in on "yes, please standardize this common practice."
Post reply on HN