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

441–450 of 978 posts

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

#441

Post by hedora »

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

I’ve had good luck (in C++) replacing the underlying memory allocator with one that tracks leaks by allocation type (which is fast enough for production use).

This can be done in C, but the calling code has to spell malloc and free differently.

In debug mode, configuring malloc to poison (and add fences) on allocation and free finds most of the remaining things.

These techniques tend to have much lower runtime overhead than valgrind (2-digit percentages vs 5-10x), so they can be left on throughout testing and partially enabled in production.

They find >90% of the memory bugs that I write (assuming valgrind finds 100%). YMMV.

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

#442

Post by BeeOnRope »

AaronBallman wrote: post #308
BeeOnRope wrote: post #292

When deciding on standardized behavior for C operations or data representation that may favor some hardware over others [1], who argues the side of the various hardware vendors, if they have no members on the standardization committee? Is it fair to assume that hardware-related decisions occur in an environment where members who are sponsored by vendors argue their employers case, rather an a neutral one? --- [1] E.g…

> When deciding on standardized behavior for C operations or data representation that may favor some hardware over others [1], who argues the side of the various hardware vendors, if they have no members on the standardization committee? The C committee has a number of implementation vendors on it (GCC, Clang, IBM, Intel, sdcc, etc) and these folks do a good job of speaking up about the hardware they have to support…

Thanks for your quick and honest answer.

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

#443

Post by iainmerrick »

klodolph wrote: post #106
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 over…

the compiler is allowed to assume the loop terminates precisely because signed overflow is undefined.

Just to be sure I understand the fine details of this -- what would the impact be if the compiler assumed (correctly) that the loop might not terminate? What optimization would that prevent?

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

#444

Post by DougGwyn »

emilfihlman wrote: post #207
DougGwyn wrote: post #127

Earlier quoted context omitted.

We would need a specific proposal and assurance that nearly all computers can efficiently provide that service. It is more likely in the POSIX standard.

Though it's interesting that threads were added to the standard. Perhaps though they filled a niche that wasn't as well filled as select/poll/epoll/kqueue/etc had already since pthread api is perhaps harder.

I thought it would be best to standardize just a single thread, which should be the basic unit to be embedded in a good parallel-processing model. However, others prevailed.

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

#445

Post by aw1621107 »

graycat wrote: post #284

(1) Explain just how malloc() and free() work under the covers and the implications for multi-threading, memory leaks , virtual memory paging, etc. Maybe also cover some means, algorithms, and code for reporting on the state , status, etc. of the memory use by malloc() and free(). By the way, I know and have known well for longer than most C programmers have lived JUST what the heap data structure, as used in "heap s…

> Explain just how malloc() and free() work under the covers and the implications for multi-threading, memory leaks, virtual memory paging, etc. > > Maybe also cover some means, algorithms, and code for reporting on the state, status, etc. of the memory use by malloc() and free().

Strictly speaking, these are implementation details that the C standard leaves unspecified. If you want to know how the memory allocation functions work or methods for inspecting the state of the heap you'll need to look at a specific implementation (e.g., glibc, musl, jemalloc, etc.) since the details can vary wildly between implementations.

> Cover in overwhelmingly fine detail the "stack" and the chuckhole in the road, stack overflow.

Both these are not really specific to C, and there should be a lot of resources you can find that explain these concepts ([0], [1] for some example general explanations). Did you have more specific questions in mind?

> How can C exploit a processor with 64 bit addressing and main memory in the tens of gigabytes and maybe terabytes? > How can C support, i.e., exploit, integers and IEEE floating point in 64 and/or 128 bit lengths?

I think pointer/integer sizes are implementation details. C specifies pointer behavior and minimum integer sizes (and optional fixed-width types), but the precise widths are chosen by the implementation. In the case of floating-point, the sizes are specified by IEEE 754 widths.

In other words, you don't really need to do anything special as long as you pick the appropriate types as defined by your implementation.

> For C++, please explain how that works under the covers. E.g., some years ago it appeared the C++ was defined as only a source code pre-processor to C. Is this still the case?

As far as I know no (production-quality?) C++ compiler has been implemented as a source-level preprocessor for basically the entirety of C++'s existence [2]. The very first "compiler" for C++ was Cpre, back when C++ was still the C dialect "C with classes" (around October 1979), and that was indeed a preprocessor. That was replaced by the Cfront front end around 1982-1983, about when "C with classes" started gaining new features and got a new name. Cfront is a proper compiler front end that output C code, and I think from that point on C++ compilers used "standard" compiler tech.

[0]: https://stackoverflow.com/questions/79923/what-and-where-are... [1]: https://en.wikipedia.org/wiki/Stack_overflow [2]: http://www.stroustrup.com/hopl2.pdf

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

#446

Post by kazinator »

rkangel wrote: post #326
loeg wrote: post #311

Earlier quoted context omitted.

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.

It would presumably involve a new type that didn't exist in the current ABI. Those pointers would stay the same, and the new (twice as big) pointers would be used for the array feature.

On a given platform, the fat pointer type could have an easily defined ABI expressible in C90 declarations (whose ABI is then deducible accordingly).

For instance, complex double numbers can have an ABI which says that they look like struct { double re, im; };

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

#448

Post by Tronic2 »

barbegal wrote: post #354
Tronic2 wrote: post #232

Earlier quoted context omitted.

Ignore all character support in the standard library and handle UTF-8 as opaque binary buffers. If you need complex string algorithms, decode into UCS-4 (UTF-32). You'll find short encoding and decoding functions on StackOverflow. For case-insensitive comparisons and sorting, use an external library that knows the latest Unicode standard.

Except that not all binary data is valid UTF-8 so you also need functions that check if a binary buffer is valid UTF-8.

The decoding phase will do that, if needed. Also note that in many cases you must process it as opaque binary, even though it should be valid UTF-8. This is in particular with filenames on POSIX systems because otherwise you could not access any files that happen to have invalid UTF-8 in their names.

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

#449

Post by rwmj »

rseacord wrote: post #360
rwmj wrote: post #242

Earlier quoted context omitted.

Golang gets this wrong. It should be scope-level not function-level (or perhaps there should be two different types, but I have never personally had a need for a function-level cleanup). Edit: Also please review how attribute cleanup is used by existing C code before jumping into proposals. If something is added to C2x which is inconsistent with what existing code is already doing widely, then it's no help to anyone.

Yes, we have discussed adding this feature at scope level. A not entirely serious proposal was to implement it as follows: #define DEFER(a, b, c) \ for (bool _flag = true; _flag; _flag = false) \ for (a; _flag && (b); c, _flag = false) int fun() { DEFER(FILE *f1 = fopen(...), (NULL != f1), mfclose(f1)) { DEFER(FILE *f2 = fopen(...), (NULL != f2), mfclose(f2)) { DEFER(FILE *f3 = fopen(...), (NULL != f3), mfclose(f3))…

Yes, I'll ask around in Red Hat too, see if we can get some help with this.

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

#450

Post by nabla9 »

rseacord wrote: post #264
nabla9 wrote: post #151

Earlier quoted context omitted.

> no such feature has emerged in practice Arrays with length constantly emerge among C users and libraries. They are just all incompatible because without standardization there is no convergence.

Sounds like a good use of standardization. If there is existing implementation practice, please go ahead and submit a proposal. I would be happy to champion such a proposal if you can't attend in person.

It was an observation, not suggestion.

When the language standardization body has not managed to add arrays with length in 48 years, I don't think it should be added at this point. The culture is backward looking and incompatible with modern needs and people involved are old and incompatible with the future (no offense, so am I).

C standardization effort should focus on finishing the language, not developing it to match modern world. I have programmed with C over 20 years, since I was a teenager. It's has long been the system programming language I'm most familiar with. For the last 10 years I have never written an executable. Just short callable functions from other languages. Python, Java, Common Lisp, Matlab, and 'horrors or horrors' C++.

I think Standard C's can live next 50 years in gradual decline as portable assembler called from other languages and compilation target.

If I would propose new extension to C language, I would propose completely new language that can be optionally compiled into C and works side by side with old C code.

Post reply on HN