What do you think of a variant on this?
Tell HN: C Experts Panel – Ask us anything about C
491–500 of 978 posts
Re: Tell HN: C Experts Panel – Ask us anything about C
#492(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…
(7) Exactly. Please add how to free memory in standard way if there's an exception, and how not to use GoTo in such cases.
Re: Tell HN: C Experts Panel – Ask us anything about C
#493Earlier quoted context omitted.
BSD sockets are weird in that the first struct's (sockaddr) size wasn't big enough, so APIs all take a nominal pointer to sockaddr but may require larger storage (sockaddr_storage) depending on the actual address. /* * Structure used by kernel to store most * addresses. */ struct sockaddr { unsigned char sa_len; /* total length */ sa_family_t sa_family; /* address family */ char sa_data[14]; /* actually longer; addre…
struct sockaddr_storage is insufficient as well. A Unix domain socket path can be longer than `sizeof ((struct sockaddr_un){ 0}).sun_path`. That's a major reason why all the socket APIs take a separate socklen_t argument. Most people just assume that a domain socket path is limited to a relatively short string, but it's not (except possibly Minix, IIRC).
> A Unix domain socket path can be longer than `sizeof ((struct sockaddr_un){ 0}).sun_path`
Hm, I didn't realize this, or if I knew this I had forgotten. It makes sense because sun_path is usually pretty small, I believe 108 chars is the most common choice, and typically file paths are allowed to be much longer.
Do you have a citation for this behavior? I can't seem to find it, though I'm not looking very hard.
I guess you are right that any syscall taking a struct sockaddr * also has a length passed to it... Some systems have sa_len inside struct sockaddr to indicate length, but IIRC linux does not. I've often thought that length parameter was sort of redundant, because (1) some platforms have sa_len, and (2) even without that, you should be able to derive length from family. But your Unix domain socket example breaks (2). Without being able to do that, I start to imagine that the kernel would need to probe for NUL chars terminating the C string anytime it inspects a struct sockaddr_un, rather than block-copying the expected size of the structure -- that would be needlessly complicated.
Re: Tell HN: C Experts Panel – Ask us anything about C
#494Earlier quoted context omitted.
Does it concern you how aggressively compiler teams are exploiting UB?
I would say that there is a lot of concern in the committee about how compilers are optimizing based on pointer providence. There has been a study group looking at this. It now appears that they are likely to publish their proposal as a Technical Report.
What's the best way to keep an eye out for that TR? Periodically checking http://www.open-std.org/jtc1/sc22/wg14/ ?
I can't ever tell if I'm looking in the right place. :)
Re: Tell HN: C Experts Panel – Ask us anything about C
#495Earlier 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, the optimizations referred to include those that will make the program faster when N=100.
Re: Tell HN: C Experts Panel – Ask us anything about C
#496I really like the relative simplicity of C compared to C++ and recently wrote a project in C, but eventually rewrote it in C++ for just a few seemingly trivial reasons that nonetheless were important time savers. I'd love to know if the C standard, as can run on GPUs also, will ever evolve to offer:
1) namespaces, so function names don't need to be 30 characters to avoid naming collision
2) guaranteed copy elision or RVO -- provides greater confidence for common idioms and expressivity compared to passing out parameters
Re: Tell HN: C Experts Panel – Ask us anything about C
#497Earlier quoted context omitted.
This is an entire language extension, as you note. The last time various people interested in this were in the same room (it was in January 2020 in a workgroup called HACS), what emerged was that the Rust people would try to add the “secret” keyword to the language first, since their language is still more agile than C, while the LLVM people would prepare LLVM for the arrival of at least one front-end that understand…
Thanks for the update. I was encouraging some of the people who were going to be at HACS to address this but I hadn't heard the latest progress. Unfortunately I couldn't be there myself.
If I remember correctly, Chandler was the one writing down the draft for LLVM developers to comment on LLVM-side. Unfortunately, if you Google his name and the relevant keywords, the results are full of his work on speculative load hardening.
Someone who read the LLVM mailing-list attentively should have seen it and may have a link.
Re: Tell HN: C Experts Panel – Ask us anything about C
#498Earlier quoted context omitted.
The usual argument is: once you've verified some piece of code is correct, changing it (even when there should be no functional change in the semantics) carries risk. Some customers have C89-era code that compiles in C17 mode and they don't want to change that code because of these risks (perhaps the cost of testing is prohibitively expensive, there may be contractual obligations that kick in when changing that code,…
Well, one argument is that the vendors should not compile C89 code as C17. If you write C89, then stick with -std=c89 (or upgrade to the latest officially compatible revision). It makes sense to preserve language compatibility within several language revisions, gradually sunsetting some features, but why do that for the eternity? Gradual de-supporting would push the problem to the compilers, but while it is no fun su…
These are all good points, and I don't see a legitimate, technical reason to avoid deprecating and eliminating identifier list syntax in new C standards (but then, I'm not as much of an expert as some people, so I might be missing something important).
That having been said, a compiler vendor has, almost by definition as its first priority, an undeniable interest in keeping customers happy while, at the same time, ensuring strong reasons to see value in a version upgrade. When dealing with corporate enterprise customers, that often means offering new features without deprecating old features, because the customers want the new features but don't want to have to rewrite anything just because of a compiler upgrade.
They'll want C17 (and C32, for that matter) hot new features, but they will not want to pay a developer to "rewrite code that already works" (in the view of middle managers).
That's why I think they'd most likely complain. Their concerns about removing identifier lists likely have nothing at all to do with good technical sense. Ideally, if you don't want to rewrite your rickety old bit-rotting shit code, you should just continue compiling it with an old compiler, and if you want new language features you should use them in new language standard code, period, but business (for pathological, perhaps, but not really upstream-curable reasons) doesn't generally work that way.
Re: Tell HN: C Experts Panel – Ask us anything about C
#499Earlier quoted context omitted.
This is an entire language extension, as you note. The last time various people interested in this were in the same room (it was in January 2020 in a workgroup called HACS), what emerged was that the Rust people would try to add the “secret” keyword to the language first, since their language is still more agile than C, while the LLVM people would prepare LLVM for the arrival of at least one front-end that understand…
(Not OP) I would appreciate any references you can provide. An LLVM __attribute__((secret)) would be a great place to start.
Unfortunately I am out of useful information:
https://news.ycombinator.com/item?id=22868999
I hope someone will provide the next link.
Re: Tell HN: C Experts Panel – Ask us anything about C
#500Earlier quoted context omitted.
We've been discussing a paper on this ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2466.pdf ) at recent meetings and it's been fairly well-received each time, but not adopted for C2x as of yet.
It feels like it would be a real shame to standardize something that gives up the power of the Clang/GCC heterogeneous checked operations. We added them in Clang precisely because the original homogeneous operations (__builtin_smull_overflow, etc) led to very substantial correctness bugs when users had to pick a single common type for the operation and add conversions. Standardizing homogeneous operations would be wo…
>the original homogeneous operations (__builtin_smull_overflow, etc) led to very substantial correctness bugs when users had to pick a single common type for the operation and add conversions.
Hi Stephen, thank you for bringing this to our attention. David Svoboda and I are now working to revise the proposal to add a supplemental proposal to support operations on heterogeneous types. We are leaning toward proposing a three-argument syntax, where the 3rd argument specifies the return type, like:
ckd_add(a, b, T)
ckd_add(a, b)