721–730 of 978 posts
How accurate, relevant, and useful today is http://c-faq.com ?
In particular, section 6 is the best resource I know of for explaining the often counterintuitive relationship between arrays and pointers.
Earlier quoted context omitted.
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.
What about giving isdigit and friends defined behavior for any argument value that's within the range of any of char, signed char, or unsigned char? The background (I know Doug knows this): isdigit() takes an argument of type int, which is required to be either within the range of unsigned char, or have the value EOF (required to be negative, typically -1). The problem: plain char is often signed, typically with a ra…
FWIW, just looked at the man page (macos) and iswdigit() and isnumber() are mentioned.
Earlier quoted context omitted.
This attitude is terrible! Its an attitude that says that unless you know exactly every pit fall in the language by heart you have no place writing code. I guess you dont use a debugger either because you never write bugs right? And you think that every software that helps the user is for noobs right? There is an endless list of bugs that have been produced by very competent C programmers, because the compiler has si…
Huh? I just want performant code. That's why I write C, and that's why I use an optimizing compiler, and that's why I ask my compiler to optimize. I also want to write code that is reasonably generic. Thus, it will have checks and branches that cover important corner cases; they are required for completeness and correctness. But very often, all of these checks turn out to be redundant in a specific context, and an op…
if(a == NULL) log_error_and_exit(); *a = 0;
Compilers, have been known to silently remove the NULL check in code like this. Does that seem clear to you? Is this your definition of compilers delivering for you? NULL checks dont just get removed in cases where you NULL check the same value multiple times, they get removed for some very non obvious reasons.
This is why the Linux kernel now needs to be built with the compiler option -fdelete-null-pointer-checks
Compilers need to start communicating what they are doing, and I think the C spec should encourage that.
Earlier quoted context omitted.
There are "projects" underway to clean up the spec where it's viewed as either buggy, inconsistent, or underspecified. The atomics and threads sections are a coupled of example. There are efforts to define the behavior in cases where implementations have converged or died out (e.g., twos complement, shifting into the sign bit). There have been no proposals to add new array types and it doesn't seem likely at the core…
>clean up the spec Would this involve further specification of bitfields? Feel implementation defined nature of bitfields limits potential
Earlier quoted context omitted.
There are "projects" underway to clean up the spec where it's viewed as either buggy, inconsistent, or underspecified. The atomics and threads sections are a coupled of example. There are efforts to define the behavior in cases where implementations have converged or died out (e.g., twos complement, shifting into the sign bit). There have been no proposals to add new array types and it doesn't seem likely at the core…
>There have been no proposals to add new array types and it doesn't seem likely at the core language level. One alternative to adding types is to allow enforcing consistency in some structs with the trailing array: struct my_obj { const size_t n; //other variables char text[n]; }; where for simplicity you might only allow the first member to act as a length (and it must of course be constant). The point is that then…
Earlier quoted context omitted.
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.
What about giving isdigit and friends defined behavior for any argument value that's within the range of any of char, signed char, or unsigned char? The background (I know Doug knows this): isdigit() takes an argument of type int, which is required to be either within the range of unsigned char, or have the value EOF (required to be negative, typically -1). The problem: plain char is often signed, typically with a ra…
Earlier quoted context omitted.
C++ introduces a shit-ton of stuff that one often doesn't want, and even Bjarne Stroustrup (who many content has never seen a language feature he didn't want) has been a little alarmed at the sheer mass of cruft being crammed into recent updates to the standard. I know many C++ people think C++ is pure improvement over C in all contexts and manners, but it's not. It's different, and there are features implemented in…
> C++ introduces a shit-ton of stuff that one often doesn't want The point in my comment is that every single item in C++ was wanted and championed by someone , exactly like all the talk about adding this and that to C. > C shouldn't turn into C++ Well, C did turn into C++. The entity that gave forth C++ is C. Analogy: when we say "apes turned into humans", we don't mean that apes don't exist any more or are not cont…
Earlier quoted context omitted.
> But the compiler is like "hey! you used the result of this function as an index for this array! i must be in the range [0, 10)! I can use that information!" As a developer who has seen lots of developers (including himself) make really dumb mistakes, this seems like a very strange statement. Imagine if you hired a security guard to stand outside your house. One day, he sees you leave the house and forget to lock th…
> in a lot of cases, it will be harmless; and in the worst case it will crash with a segfault. I am not sure if a segfault is always the worst case. It could be by some coincidence that array[i] contains some confidential information [maybe part of a private key? 32 bits of the user's password?] and you've now written it to a log file. I know it's hard to imagine a mis-read of ~32 bits would have bad consequences of…
I 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.
Your proposal replaces my use of an array with two things, a pointer (as before) and a length. This is not too helpful, because I already could have done that if I'd wanted to.
What is missing is the ability to pass an array. Sometimes I want to toss a few megabytes on the stack. Don't stop me. I should be able to do that. The called function then has a copy of the original array that it can modify without mangling the original array in the caller.
Many of your remaining questions have devolved into "When will I see my favorite feature xyz appear in the C Standard?" The answer in most cases is "that depends on how long it takes you to submit a proposal". Take a look at http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log... for previous proposals and review the minutes to see which proposals have been adopted. In general, the committee is not going to a…