Will Effective C cover the strict aliasing rule and also why the BSD sockets API seems to get away with it (e.g. (sockaddr *) &sockaddr_in)?
I don't think the book covers strict aliasing, at least not in detail.
Tell HN: C Experts Panel – Ask us anything about C
611–620 of 978 posts
Re: Tell HN: C Experts Panel – Ask us anything about C
#612Earlier quoted context omitted.
> 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 gue…
So I just reran some tests on my existing VMs and it turns out I remembered wrong. Here's the actual break down: * Solaris 11.4: .sun_path: 108; bind/connect path maximum: 1023. Length seems to be same as open. Interestingly, open path maximum seems to be 1023 (judged by trying ls -l /path/to/sock), although I always thought it was unbounded on Solaris. * MacOS 10.14: .sun_path: 104, bind/connect path maximum: 253. L…
Linux also has the unusual extension of: if sun_path[0] is NUL, the path is not a filesystem path and the rest of the name buffer is an ID. I don't remember if that can have embedded NULs in that ID. I believe so.
Re: Tell HN: C Experts Panel – Ask us anything about C
#613Now 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?
> 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? I presume you'd want signed overflow to have the usual 2's-complement wraparound behavior. One problem with that is that a compiler (probably) couldn't warn about overflows that are actually errors. For example: int n = INT_MAX; /* ... */ n++; With integer overf…
> In the code above, is there any sense in which INT_MIN is the "right" answer for any typical problem domain?
There is no answer different that INT_MIN that would be right and make sense, i.e. the natural properties of the + operator (associativity, commutativity) are respected. Thus, by want of another possibility, INT_MIN is precisely the right answer to your code.
I read your code and it seems to me very clear that INT_MIN is exactly what the programmer intended.
Re: Tell HN: C Experts Panel – Ask us anything about C
#614Is there a chance to ever see C++-template-like features appear in C? For instance, a lot of redundant code (or ugly macro business) could be neatly replaced by function templates. Even just template functions with only POD values allowed would be a great readability improvement.
It's already there. It's called C++ templates
Re: Tell HN: C Experts Panel – Ask us anything about C
#615I wrote about a simple addition to C that could eliminate most buffer overflows: https://www.digitalmars.com/articles/C-biggest-mistake.html I.e. offering a way that arrays won't automatically decay to pointers when passed as a function parameter.
Arrays are pointers. If they aren't pointers then you need to copy the data when you are giving an array as a function parameter. that's a lot slower. Being able to prepare an set of data in an array and then giving a pointer to a function is very useful. You could add a second type of array on top of what you have in C that includes more stuff, but if that's what you want you can implement that yourself with a struct.
Re: Tell HN: C Experts Panel – Ask us anything about C
#616A few proposals: Why not mandate a warning every time the compiler detects and makes use of UB? It would solve SO many issues. If you are looking to improve security of C programs, then letting the user know what the compiler does should be number one. Try to convert as many UB's to Platform specific, as possible would also be a big help. I would love to see native vector types. Its time. Vector types are now more co…
> Why not mandate a warning every time the compiler detects and makes use of UB? It would solve SO many issues.
Because that's hardly ever what happens, except when it actually does, and compilers do an increasingly good job of issuing diagnostics in that case. If you actually mandated it, no compiler today would come close to being standards compliant. This comes close to making the language unimplementable.
The most common issue with UB and optimizations is not that "compiler detects UB and does something with it," it's that compiler analyzes and optimizes code with the assumption that UB doesn't actually happen. It doesn't know whether it does (and in general, it is impossible to tell whether it would happen -- it's something that might or might not happen at run time, and proving it one way or another amounts to solving the halting problem), it just assumes it doesn't.
And if one mandated compilers to report every time they make an optimization that is valid under the assumption that the program is well behaved, then you would never finish reading compiler output. Or you would turn off optimizations.
Re: Tell HN: C Experts Panel – Ask us anything about C
#617Earlier quoted context omitted.
This is a common misconception (or poor way of phrasing it, sorry). Compiler implementers don't go looking for instances of undefined behavior in a program with the goal of optimizing it in some way. There is little value in optimizing invalid code. The opposite is the case. But we must write code that relies on the same rules and requirements that programs are held to (and vice versa). When either party breaks those…
> This is a common misconception (or poor way of phrasing it, sorry). Compiler implementers don't go looking for instances of undefined behavior in a program with the goal of optimizing it in some way. There is little value in optimizing invalid code. The opposite is the case. Compilers do deliberately look to optimize loops with signed counters by exploiting UB to assume that they will never wrap.
Well yes, they assume they never wrap because that is not allowed by the language, by definition.
UB are the results of broken preconditions at the language level.
Re: Tell HN: C Experts Panel – Ask us anything about C
#618Does the committee have plans to deprecate (as in: give compiler license to complain suchthat compiler developers can appeal to yhe standard when users complain back) locale-sensitive functions like isdigit, which is useless for processing protocol syntax, because it is locale-sensitive, and useless for processing natural-language text, because it examines only one UTF-8 codw unit?
isdigit is likely to remain, because much existing code does use it (perhaps in different contexts from the one you cited). If you need a different function specification to do something different, it could be added in a future release, but that doesn't mean that we need to force programmers to change their existing code.
Does there exist a use case in portable code such that use of isdigit is not a bug?
How does the committee view non-portable existing code generally when considering changes?
Re: Tell HN: C Experts Panel – Ask us anything about C
#619Earlier quoted context omitted.
Do you find the learning curve for C to be high? I find it quite the opposite. It's a simple language with only a few concepts to learn, once you got those, that's it. There might be some preprocessor tricks you'll pick up later, but the base language and library is pretty comprehensive IMHO.
> It's a simple language with only a few concepts to learn I mean by that logic, Assembly could be deem even simpler, yet writing OR reading programs in Assembly is absolutely not simple at all. At the end of day, one has to write programs that solve (complicated) problems, and learning how to do that in C is difficult, thus the learning curve deemed higher when it comes to writing professional C. I can guarantee you…
Modern assembly language has a huge set of instructions, that make them hard to learn, but the concept is still easy to learn.
Re: Tell HN: C Experts Panel – Ask us anything about C
#620Earlier 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.
typedef struct {uint8_t *data; size_t len;} ByteBuf; is the first line of code I write in a C project.
Another option is a struct with a FAM at the end.
typedef struct {
size_t len;
uint8_t data[];
} ByteBuf;
ByteBuf *b = malloc(sizeof(*b) + sizeof(uint8_t) * array_size);
b->len = array_size;