281–290 of 978 posts
Earlier quoted context omitted.
It's not commonly available though, e.g. on Linux/BSD systems...
Correct -- it would be nice if the glibc maintainers would reconsider their opinion of supporting the optional Annex K functionality. There is definitely user demand for the feature.
Earlier quoted context omitted.
Clang and GCC's approach for these operations is even nicer FWIW (__builtin_[add/sub/mul]_overflow(a, b, &c)), which allow arbitrary heterogenous integer types for a, b, and c and do the right thing. I know there's recently been some movement towards standardizing something in this direction, but I don't know what the status of that work is. Probably one of the folks doing the AUA can update.
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.
The generic heterogeneous operations also avoid the identifier blowup. The only real argument against them that I see is that they are not easily implementable in C itself, but that's nothing new for the standard library (and should be a non-goal, in my not-a-committee-member opinion).
Obviously, I'm not privy to the committee discussions around this, so there may be good reasons for the choice, but it worries me a lot to see that document.
Does the following code fragment cause undefined behaviour? unsigned int x; x -= x; There's a lengthy StackOverflow thread where various C language-lawyers disagree on what the spec has to say about trap values, and under what circumstances reading an uninitialised variable causes UB. I'd appreciate an authoritative answer. Thanks for dropping by on HN! https://stackoverflow.com/q/11962457/
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 sort", is. But what is the meaning of "the heap" in C programming language documentation?
(2) Cover in overwhelmingly fine detail the "stack" and the chuckhole in the road, stack overflow.
(3) Where to get a reliable package for a reasonable package of code for handling character strings -- what I saw and worked with in C is not reasonable.
(4) From the C programming I did, it looks like a large C program for significant work involves some hundreds, maybe tens of thousands, of includes, inserts, whatever, and what a linkage editor would call external references. There must somewhere be some tools to help a programmer make sense of all those includes and references, the resulting memory maps, issues of locality of reference, word boundary alignment, etc.
(5)How can C exploit a processor with 64 bit addressing and main memory in the tens of gigabytes and maybe terabytes?
(6) How can C support, i.e., exploit, integers and IEEE floating point in 64 and/or 128 bit lengths?
(7) How to handle exceptional conditions with, say, non-local gotos and without danger of memory leaks?
(8) Sorry, but far and away my favorite programming language long has been and remains PL/I, especially for its scope of names rules, handling of aggregates with external scope, its data structures, and its exceptional conditional handling with non-local gotos and freeing automatic storage and, thus, avoiding memory leaks. Of course I can't use PL/I now, but the problems PL/I solved are still with us, also when writing C code. So, how to solve these problems with C code?
(9) 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? If so, then explaining C++ under the covers should be feasible and valuable.
I love how small of a language C is and get concerned when people recommend adding feature x,y and z. What's the plan for C over the next 5 - 10 years?
Earlier quoted context omitted.
You can very easily make a struct consisting of a pointer and length, is adding such a thing to the standard really a big deal? Personally, I don't see a problem with passing two arguments.
- In your example there's no guarantee that the length will be accurate, or that the data hasn't been modified independently elsewhere in the program. - In other words you've created a fantastic shoe-gun. One update line missed (either length or data, or data re-used outside the struct) and your "simple" struct is a huge headache, including potential security vulnerabilities. - Re-implementing a common error prone th…
And having a special data-and-length type would make these guarantees... how? You're ultimately going to need to be able to create these objects from bare data and length somehow, so it's a case of garbage-in-garbage-out.
Earlier quoted context omitted.
Great question! Joining the committee requires you to be a member of your country's national body group (in the US, that's INCITS) and attend at least some percentage of the official committee meetings, and that's about it. So membership is not difficult, but it can be expensive. Many committee members are sponsored by their employers for this reason, but there's no requirement that you represent a company. I joined…
Related to that: C++ standards body seems to be quite open allowing non-members to participate (outside official votes, while respecting them when looking for consensus) is it just due to my limited observation or is the C group less open? Any plans in that regard?
Will you ever add / have you considered adding sane formatting options for fixed length variables in printf? Say %u32 or %s64 ? Have you considered adding access to structure members by index or by string name? Have you considered dynamic structures?
Just FYI -- there are macros for the fixed-length types, e.g.: printf("U32: %" PRIu23 ", U64: " PRId64, (uint32_t)1, (int64_t)2); Perhaps not as handy as %u32 or %s64, but it's here.
When will C gain a mechanism for "do not leave this sensitive information laying around after this function returns"? We have memset_s but that doesn't help when the compiler copies data into registers or onto the stack.
Is this enough to answer your question? I can look up the names of the people that were involved and communicate them privately if you are further interested.
Any plans to add semantics for exceptional situations such as divide by zero and dereferencing a null pointer? https://blog.regehr.org/archives/232 Or incorporating features from this 14 item list? https://blog.regehr.org/archives/1180 As it appears these have failed: https://blog.regehr.org/archives/1287
Making C friendlier is always a good idea, and I think the committee is (slowly) working towards this goal. I would have to examine these papers by John Regehr in more detail. Looking quickly at his proposals I can see why there he couldn't find consensus for these ideas as some of them do appear controversial.
An example of a friendly dialect of C is always is C0 (C-naught) from CMU. I don't think I'm exaggerating when I say that this language has not "caught on".