18 ms·

Conflating pointers with arrays: C's biggest mistake? (2009)

260 points by etrevino 8y ago

rurban 8y ago
The mentioned Safe C Library is now at https://github.com/rurban/safeclib https://github.com/rurban/safeclib
- pjmlp 8y ago
  The problem with secure C11 Annex K functions, is that they are only secure in name. They are still as insecure as any traditional C string and memory function. Yes, they sorted out the issues about then a string always gets its null terminator. However given that buffer and size are still two different parameters, the issue of mixing up the values is still present.
  - rurban 8y ago
    Nope. The buffer size is checked at compile-time. Much like glibc fortify, just better. There's no chance to mix them up. Even the spec'd unsafeties of the truncating n versions are fixed.
    - pjmlp 8y ago
      Can you please explain how strcpy_s() validates that dest actually points to a memory region with enough space for destsz bytes? https://en.cppreference.com/w/c/string/byte/strcpy https://en.cppreference.com/w/c/string/byte/strcpy
robert_foss 8y ago
Fair enough. Arrays losing dimensionality when passed through functions is a pain every now and then.
MrBingley 8y ago
I absolutely agree. Adding an array type to C that knows its own length would solve so many headaches, fix so many bugs, and prevent so many security vulnerabilities it's not even funny. Null terminated strings? Gone! Checked array indexing? Now possible! More efficient free that gets passed the array length? Now we could do it! The possibilities are incredible. Sadly, C is so obstinately stuck in its old ways that adding such a radical change will likely never happen. But one can dream ...
- ars 8y ago
  > But one can dream ... There's nothing stopping you from simply doing it. With a couple of macros the whole thing can just be a header file. True, it doesn't take you all the way there (you'll still need to manually check array access to make sure they don't go over), but it's a start. And those manual checks can be a macro as well, to make it easy to add them where needed.
  - slededit 8y ago
    Malloc already includes a length and most arrays are heap based. I wish it could be exposed in a nice way. Of course it would have to support sub allocators or it wouldn't be C.
    - ric129 8y ago
      There's malloc_usable_size[1], assuming you mean asking the memory allocator what the array size is. But chances are that wouldn't work correctly, because what the amount of memory a malloc calls gives you and the amount you requested are often not the same. Modern memory allocators round up the request size to the nearest "size class". [1]: http://man7.org/linux/man-pages/man3/malloc_usable_size.3.html http://man7.org/linux/man-pages/man3/malloc_usable_size.3.ht...
- webkike 8y ago
  Adding anything to C is such a useless exercise because we've made so many advancements in plt since it's release we might as well make a new language.
earenndil 8y ago
> Notable among these are C++, the D programming language, and most recently, Go I would remove go from that list, and add rust and zig.
- dosshell 8y ago
  This was written in 2009, didn't rust first appeared in 2010?
  - lightgreen 8y ago
    Why was it posted now without a year in square brackets? That was misleading.
    - jibal 8y ago
      The year is in parentheses in the title, and of course it's in the article. I for one have learned to always look at the date something was written. It irks me that there are so many web pages with time-relevant content that contain no date.
Drdrdrq 8y ago
Meh. What do you do with the dynamically allocated arrays then? Do you pass their dimensions alongside pointer? If that bothers you so much, you can create a struct that holds the pointer and metadata, and do the checks yourself. Calling this "C's biggest mistake" is a bit sensationalistic. EDIT: besides, you should start new projects in Rust anyway, because it takes security to whole other level. C did a great job, but it's a bit old. :)
- adamnemecek 8y ago
  The pattern is very present in all c code and rolling your own just causes paid when interacting with 3rd party code.
- PeCaN 8y ago
  >besides, you should start new projects in Rust anyway Thanks, I almost forgot what website I was on for a second.
  - deleted 8y ago
    [deleted]
  - Drdrdrq 8y ago
    No problem - happened to me 6 hours ago too. </s>
- int_19h 8y ago
  > Do you pass their dimensions alongside pointer That is literally the meaning of "fat pointer", and the linked article even explains it.
- jibal 8y ago
  The article explains why it's C's biggest mistke, and neither your nor anyone else has refuted it ... in fact, you don't even touch on it.
User23 8y ago
This is a very good article that highlights the importance of semantics.
WalterBright 8y ago
Apparently someone posted this here because of my remark:https://www.reddit.com/r/programming/comments/90ov9i/a_response_to_a_comment_on_the_riscv_isadev_list/e2thyts/ https://www.reddit.com/r/programming/comments/90ov9i/a_respo... Nice to see it get such a nice response!
altrego99 8y ago
Agree that this is a problem (if the programmer is not careful). But serious question, why even bother with this one fix? The only reason for the fix is so to make it more difficult to make errors. Fix arrays, then you would fix null pointer, then you might add objects, templating/generics to support a good collections library, rtti, and before you know it you are creating another one of c++, D, go, java. And we already have those. C paved the way. Why not let it be the end of it?
- WalterBright 8y ago
  Because buffer overflows are probably the number 1 security bug in C programs.
  - ahmedalsudani 8y ago
    I was wondering why you were championing this idea and agreeing with the posted link in almost every way. Then I went back to the link and figured it out :) P.S. thank you for everything you have done with D. I read in another HN thread about Better C, and it convinced me that D is the language I should be investing my time in learning and using.
    - bachmeier 8y ago
      > I read in another HN thread about Better C A good tool to check out, but which hasn't been promoted much because it's new, is dpp[1]. You can directly reference C header files in your D code. With that, betterC mode becomes a viable option for adding to an existing C project. [1] https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
- pjmlp 8y ago
  Paved the way for what? Mainstream security exploits? There were OSes being written in better languages outside Bell Labs, had it been allowed to sell UNIX instead of giving it away for a symbolic price to universities, and the historical outcome would have been completely different.
bluetomcat 8y ago
Quite surprised to see this not mentioned. C99 allows you to use the "static" keyword in array function parameters like this: void foo(int arr[static 10]); It cannot check whether a passed pointer will point to enough space, but the compiler can warn you if you pass a fixed-size array of a smaller size.
- WalterBright 8y ago
  Dynamic arrays are far, far more common than static ones.
  - bluetomcat 8y ago
    I beg to differ. In C especially, static arrays are quite common as struct members and as static objects at file scope, because dynamic allocations are a pain to manage and unnecessary when the maximum expected size is reasonably small. When the size of such arrays is computed at compile-time via macro definitions, that feature is quite handy.
    - WalterBright 8y ago
      > when the maximum expected size I pretty much never use static arrays because if I do I always without fail get a bug report when some user exceeds it.
    - jibal 8y ago
      "In C especially, static arrays are quite common as struct members and as static objects at file scope" Not among good programmers (unless the array is immutable).
drfuchs 8y ago
The proposal here is way too vague. And if you flesh it out, things start to fall apart: If nul-termination of strings is gone, does that mean that the fat pointers need to be three words long, so they have a "capacity" as well as a "current length"? If not, how do you manage to get string variable on the stack if its length might change? Or in a struct? How does concatenation work such that you can avoid horrible performance (think Java's String vs. StringBuffer)? On the other hand, if the fat pointers have a length and capacity, how do I get a fat pointer to a substring that's in the middle of a given string? Similar questions apply to general arrays, as well. Also: Am I able to take the address of an element of an array? Will that be a fat pointer too? How about a pointer to a sequence of elements? Can I do arithmetic on these pointers? If not, am I forced to pass around fat array pointers as well as index values when I want to call functions to operate on pieces of the array? How would you write Quicksort? Heapsort? And this doesn't even start to address questions like "how can I write an arena-allocation scheme when I need one"? In short, the reason that this sort of thing hasn't appeared in C is not because nobody has thought about it, nor because the C folks are too hide-bound to accept a good idea, but rather because it's not clear that there's a real, workable, limited, concise, solution that doesn't warp the language far off into Java/C#-land. It would be great if there were, but this isn't it.
- WalterBright 8y ago
  I happened to know the idea does work, and has been working in D for 18 years now. > If nul-termination of strings is gone, does that mean that the fat pointers need to be three words long, so they have a "capacity" as well as a "current length"? No. You'll still have the same issues with how memory is allocated and resized. But, once the memory is allocated, you have a safe and reliable way to access the memory without buffer overflows. > If not, how do you manage to get string variable on the stack if its length might change? Or in a struct? How does concatenation work such that you can avoid horrible performance (think Java's String vs. StringBuffer)? As I mentioned, it does not address allocating memory. However, it does offer one performance advantage in not having to call strlen to determine the size of the data. > On the other hand, if the fat pointers have a length and capacity, how do I get a fat pointer to a substring that's in the middle of a given string? In D, we call those slices. They look like this: T[] array = ... T[] slice = array[lower .. upper]; The compiler can insert checks that the slice[] lies within the bounds of array[]. > Am I able to take the address of an element of an array? Yes: `T* p = &array[3];` > Will that be a fat pointer too? No, it'll be regular pointer. To get a fat pointer, i.e. a slice: slice = array[lower .. upper]; > How about a pointer to a sequence of elements? Not sure what you mean. You can get a pointer or a slice of a dynamic array. > Can I do arithmetic on these pointers? Yes, via the slice method outlined above. > If not, am I forced to pass around fat array pointers as well as index values when I want to call functions to operate on pieces of the array? No, just the slice. > How would you write Quicksort? Heapsort? Show me your pointer version and I'll show you an array version. > And this doesn't even start to address questions like "how can I write an arena-allocation scheme when I need one"? The arena will likely be an array, right? Then return slices of it.
analognoise 8y ago
Fat Pointers - Pascal has had them since I think the beginning? So...30+ years later, we decide Pascal was right. Just saying. Shoutout to FreePascal/Lazarus!
- WalterBright 8y ago
  In Pascal, every array with a different dimension was a different type.
  - clouddrover 8y ago
    That was true in the past, but Pascal has had dynamic arrays for over twenty years. The current versions of Free Pascal and Delphi are nice to use.
    - WalterBright 8y ago
      I kinda gave up on Pascal 35 years ago when I picked up a copy of K+R :-) The only thing I really liked from Pascal were the nested functions, which I put in D.
  - pjmlp 8y ago
    That was already sorted out in early 80's Pascal dialects, even ISO Extended Pascal included support for it.
- TimJYoung 8y ago
  I keep reading articles like this on HN, and coming to the same conclusions as yourself over and over: why isn't Object Pascal more popular ? It solves many issues that have presented themselves over the last decade or so in various, more-popular languages, without any major downsides. I'm talking the language here - the RTL/system libraries and ecosystem is something that I think solves itself once more people start using the language. Is it really just about the issues with begin..end and verbosity ???
  - analognoise 8y ago
Animats 8y ago
Yes, that's C's biggest mistake. (But remember, they had to cram the compiler into a 16-bit machine.) No, "fat pointers" are not a backwards-compatible solution. They've been tried. They were a feature of GCC at one time, used by almost nobody. I once had a proposal on this. See [1]. Enough people looked it over to find errors; this is version 3. The consensus is that it would work technically but not politically. The basic idea is that the programmer knows how big the array is; they just don't have a way to tell the compiler what expression defines the length of the array. Instead of int read(int fd, char buf[], size_t n); you write int read(int n; int fd, char (&buf)[n], size_t n); It generates the same calling sequence. Arrays are still passed as plain pointers. But the compiler now knows how big "buf" is, both on the caller and callee side, and can check. I also proposed adding slice syntax to C, so, when you want to talk about part of an array, you do it as a slice, not via pointer arithmetic. The key idea here is that you can call old code from new ("strict") code, and strict code from old code. When you get to all strict code, subscript errors should be all checkable. [1] http://www.animats.com/papers/languages/safearraysforc43.pdf http://www.animats.com/papers/languages/safearraysforc43.pdf
- WalterBright 8y ago
  I suspect that the reason your idea was not adopted was the syntax. It's not a phat pointer, it's two arguments with some rather complex syntax to connect the two. The reason I'm fairly confident of that assessment is I've had similar experiences with D when the syntax for something was too complex. Early on, the syntax for lambdas was rather clunkly. Everyone either hated it, or insisted that D didn't even have lambdas. Greatly simplifying the syntax was a revelation, suddenly D had lambdas and they became used everywhere. Syntax matters a great deal.
  - Animats 8y ago
    Yes. int read(int n; int fd, char (&buf)[n], size_t n); is a bit bulky. The initial "int n;" is a little used GCC extension. Allowing int read(int fd, char (&buf)[n], size_t n); is an option. "n" is used before it is declared, which is strange for C. This is only a problem because of the UNIX idiom that buffer pointer comes before size in most system calls. char (&buf)[n] is also a bit bulky, but that, too, is forced by C/C++ tradition. char &buf[n] would be an array of refs, and char buf[n] would be an array passed by copy. There have been many, many attempts to "fix" C in a non-backwards compatible way. The result is always a new language. It's the backwards compatibility that's hard.
Annatar 8y ago
I don’t understand what the hoopla is about: in assembler we deal with arrays by having to know the size of each field without giving it a second thought. The solution is to learn assembler first, then move on to C. And AWK, as the next generation C doesn’t have this problem, or any of the C problems.
- WalterBright 8y ago
  I've written a lot of assembler code (including Empire in 100% assembler https://github.com/DigitalMars/Empire-for-PDP-11 https://github.com/DigitalMars/Empire-for-PDP-11) Assembler programs are very tedious to write, and so they tend to be rather small. You don't get any help from the non-existent compiler for even simple HLL features like static type checking.
  - Annatar 8y ago
    As a demo scene coder, I have to disagree vehemently: assembler is a joy to write, at least on MC68000 and 6502 (Amiga and C=64). The only reason why I don’t write code in assembler but in C on UNIX is becuase of portability. To me, C is nothing more than a portable assembler with the extra unnecessary code because of the inefficiencies of optimizing compilers.
- pjmlp 8y ago
  There are quite a few reasons why using Assembly in 2018 is very niche.
  - Annatar 8y ago
    What exactly are the arguments for that statement?
    - pjmlp 8y ago
      In the age of IoT and distributed computing we need portability, Assembly is the opposite of that. For stuff like SIMD we have compiler intrisics, loop vectorization and compute shaders. Even when writing straight Assembly, unless we are talking about a PIC class processor, the amount of opcodes and their behaviors across a CPU family are so broad no human manages to fit the instruction manuals on their head, several thousand pages long. Modern CPUs, aren't a Z80 on a Speccy where we could fit the opcodes and memory map on our head. So it is constrained to things like a few hundred KB PICs, people writing compiler backends, software decoding for video/audio codecs or kernel level drivers, a very specialized set of tasks, the very definition of niche.
speedplane 8y ago
Gimme a break, making stricter requirements on C arrays may theoretically make some things easier, but we’re talking 1% improvement. What makes C hard (and great) is requiring an understanding of not just memory, but memory allocation and deallocation schemes. For many beginners this is hard conceptually, but for everyone, keeping track of allocated and unallocated memory is extremely difficult.
- WalterBright 8y ago
  My proposal is purely additive, you won't need to use it at all if you don't want to. But I suspect you'll gravitate towards it over time, most everyone does (experience with D dynamic arrays).
- mankash666 8y ago
  Disagree. C was the first language I/we learnt, and it's still my favorite. It's a bit like the first language you learn. For someone from the Latin family of languages, Mandarin's verbal & written structure might seem hard, but for native Chinese, it's second nature.
  - speedplane 8y ago
    Mandarin may be your first and favorite, but that doesn't make it easy to learn. Same with C.
nurettin 8y ago
Fat pointers manifested themselves in Pascal as strings and are still being used in modern Delphi.
chmike 8y ago
From my experience Go's array (slice) is a far better solution. It does not only carry the size (number of elements), it also carries the array buffer capacity. To me it's the epitome of what arrays should be.
- zaphirplane 8y ago
  Usually people have to refer to a slice cheat sheet to work with it, perhaps it’s not an intuitive concept/api
  - burntsushi 8y ago
    That's because of a lack of named methods to perform common operations. It has nothing to do with the fact that slices are fat pointers. Also, nobody I know constantly looks at a cheat sheet. The concepts motivating the various slice transformations get ingrained pretty quickly.
deleted 8y ago
[deleted]
kyberias 8y ago
Why does the author of D want to "fix" C by changing it into D? Concentrate on that D language.
- alphaglosined 8y ago
  You see, before D ever existed, Walter wrote a C/C++ compiler professionally. That is why he would like to see C improved. He has just as much interest in seeing it improved as you or I do. In fact, I would say he has more reason as he has dedicated a good part of his life towards it...
- WalterBright 8y ago
  I like to fix things. Why not share a simple and effective fix?
  - kyberias 8y ago
    Isn't there a standards organization / body for C language. Have you proposed this there? What was the outcome?
- pjmlp 8y ago
  Because it is clear to us, advocates of safer systems programming languages, that no one is going to rewrite POSIX based platforms in something else. So we would like to improve our foundations, to move UNIX derived OSes to some kind of safer C, instead of having it be the backdoor of the whole security infrastructure.
- jibal 8y ago
  > Why does the author of D want to "fix" C What's the downside? > by changing it into D? That comment is tendentious, hyperbolic, and generally credibility-damaging. > Concentrate on that D language. You think he doesn't?
okket 8y ago
(2009) See also discussion from 9 years ago: https://news.ycombinator.com/item?id=1014533 https://news.ycombinator.com/item?id=1014533 (47 comments)
auslander 8y ago
OpenBSD replaced strcat by strlcat, strcpy by strlcpy 20 years ago, in OpenBSD 2.4. They are implemented in the C libraries for OpenBSD, FreeBSD, NetBSD, Solaris, OS X, and QNX. They have not been included in the GNU C library used by Linux.
- medecau 8y ago
  A few years ago I remember seeing strl* mentioned in a slide presentation for something that must have come from the oBSD camp. Since then I thought, not knowing any amount of C, that strl* was part of the language and available to all. Imagine if you will my confusion everytime I read people complaining about C being insecure. Your comment corrected my perception of this. Thank you.
  - auslander 8y ago
    I admire the no-nonsense approach by OpenBSD: "The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better." https://www.openbsd.org/security.html https://www.openbsd.org/security.html I'm in DevOps field, and this 'make it right from the start' resonates strongly with me. Richard Feynman: Disregard others :)
- WalterBright 8y ago
  Those functions have a separate length parameter. There is no way to mechanically check that the length argument accurately reflects the length of the string. It's not an effective solution.
  - pjmlp 8y ago
    Which is the reason why I consider the C11 security annex, anything but safe.
  - auslander 8y ago
hota_mazi 8y ago
Conflating pointers and arrays seem pretty minor and not the cause for many bugs. The main source of bugs in C to me would be pointer arithmetics.
- WalterBright 8y ago
  Pointer arithmetic is mainly used to access arrays, and is where the buffer overflows come from. Using actual arrays instead allows the compiler to insert overflow checking code.
nearmuse 8y ago
What's the mistake? You pass a pointer and the number of elements, it's just the C way. At any point in time you have to pay attention. What is the proposal here? Make all arrays structures? Or add some weird un-C syntactic sugar?
- SamReidHughes 8y ago
  It's a question of priorities. It depends whether your goal is to maximize productivity and minimize the defect rate, or if your goal is to tell people they need to pay attention.
- jibal 8y ago
  "What is the proposal here?" You're commenting without reading the article?
IshKebab 8y ago
I feel like Sibiu should just write a new language that is C with fixes, and no more.
- pjmlp 8y ago
  Has been tried a couple of times, the problem is mostly human not technical.
the_duke 8y ago
Should have a 2009 in the title.
xroche 8y ago
This is IMHO by far NOT C' biggest mistake. Not even close. A typical compiler will even warn you when you do something stupid with arrays in function definitions (-Wsizeof-array-argument is the default nowadays). On the other hand, UBE (undefined, or unspecified behavior) are probably the nastiest stuff that can bite you in C. I have been programming in C for a very, very long time, and I am still getting hit by UBE time to time, because, eh, you tend to forget "this case". Last time, it took me a while to realize the bug in the following code snippet from a colleague (not the actual code, but the idea is there): struct ip_weight { in_addr_t ip; uint64_t weight; }; const struct ip_weight ipw1 = {0x7F000001, 1}; const struct ip_weight ipw2 = {0x7F000001, 1}; const uint32_t hash1 = hash_function(&ipw1, sizeof(ipw1)); const uint32_t hash2 = hash_function(&ipw2, sizeof(ipw2)); The bug: hash1 and hash2 are not the same. For those who are fluent in C UBE, this is obvious, and you'll probably smile. But even for veterans, you tend to miss that after a long day of work. This, my friends, is part of the real mistakes in C: leaving too many UBE. The result is coding in a minefield. [You probably found the bug, right ? If not: the obvious issue is that 'struct ip_weight' needs padding for the second field. And while all omitted fields are by the standard initialized to 0 when you declare a structure on the stack, padding value is undefined; and gcc typically leave padding with stack dirty content.]
- senatorobama 8y ago
  Why is struct ip_weight padded.. is it to make it word aligned on 64-bit platforms?
  - blattimwind 8y ago
    in_addr_t is a 32 bit integer. On 64 bit archs this will usually result in a 32 bit padding for word alignment.
    - deleted 8y ago
      [deleted]
  - pandaman 8y ago
    To align 'weight' member on its size.
toolslive 8y ago
Isn't the fact that core types don't have a fixed representation a bigger mistake ? a char can be 16 bits, for example, aso.
- WalterBright 8y ago
  The unfixed type sizes are mostly just a nuisance, though I've wasted a lot of time dealing with them.
  - p0nce 8y ago
    It can also create untold naming conflicts.
- flingo 8y ago
  When can a char be 16 bits? I presume it'd still have a sizeof() of 1 though.
  - toolslive 8y ago
    Texas Instruments C54x DSPs It can even be funkier, like 12 bits in a char https://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char https://stackoverflow.com/questions/2098149/what-platforms-h... It's a mess
  - WalterBright 8y ago
    I've seen 32 bit chars on some DSP C implementations.
  - jibal 8y ago
    "When can a char be 16 bits?" Whenever an implementation says so. There are now few machines where the addressable unit is not 8 bits though, which is why languages like D and Java can get away with not supporting them. > I presume it'd still have a sizeof() of 1 though. The language standard requires that.
- hcs 8y ago
  Also char not specified in the language as signed or unsigned...
xaduha 8y ago
That's why I hope Red/System and just Red in general takes off https://static.red-lang.org/red-system-specs.html https://static.red-lang.org/red-system-specs.html
WalterBright 8y ago
Just for fun, type in this program: int fred(int a[10]) { return a[11]; } It compiles without error with gcc and clang, even with -Wall. The code generated by clang is: mov EAX,02Ch[RDI] ret i.e. buffer overflow, even though the array size is given. Compile the equivalent DasBetterC program: int fred(ref int[10] a) { return a[11]; } fred.d(2): Error: array index 11 is out of bounds a[0 .. 10] And the 32 bit code generated (when using 9 instead of 11 so it will compile): mov EAX,024h[EAX] ret
bluecalm 8y ago
Why is this such a serious issue? I mean it is inconvenient to always pass length along with the pointer but it's not that inconvenient. It's a bit more typing but that's where problems end.
apz28 8y ago
I would love one day that programming should adhere to the discipline as in bridge/car safety. Simple malpractice will go to jail for it then there will be no argumment/discussion about this stupid mistake that can be verified by tool Cheers Pham
flingo 8y ago
Is it better to pass the length of the array, or a pointer to the last valid address in the array? (or one past that) There's probably an advantage in the two types being the same. Thought of this as I was reading the article.
- jibal 8y ago
  The length is better, since that's almost always what you want. > There's probably an advantage in the two types being the same. Not really.
rebootthesystem 8y ago
My guess is this won't be a popular post given the average age of HN participants. There's nothing whatsoever wrong with C. The problem are programmers who grew up completely and utterly disconnected from the machine. I am from that generation that actually did useful things with machine language. I said "machine language" not "assembler". Yes, I am one of those guys who actually programmed IMSAI era machines using toggle switches. Thankfully not for long. There is no such thing as an "array". That's a human construct. All you have is some registers and a pile of memory with addresses to go store and retrieve things from it. That's it. That is the entire reality of computing. And so, you can choose to be a knowledgeable software developer and be keenly aware of what the words you type on your screen actually do or you can live in ignorance of this and perennially think things are broken. In C you are responsible for understanding that you are not typing magical words that solve all your problems. You are in charge. An array, as such, is just the address of the starting point of some bunch of numbers you are storing in a chunk of memory. Done. Period. Past that, one can choose to understand and work with this or saddle a language with all kinds of additional code that removes the programmer from the responsibility of knowing what's going on at the expense of having to execute TONS of UNNECESSARY code every single time one wants to do anything at all. An array ceases to be a chunk-o-data and becomes that plus a bunch of other stuff in memory which, in turn, relies on a pile of code that wraps it into something that a programmer can use without much thought given. This is how, for example, coding something like a Genetic Algorithm in Objective-C can be hundreds of times slower than re-coding it in C (or C++), where you actually have to mind what you are doing. To me that's just laziness. Or lack of education. Or both. I have never, ever, had any issues with magical things happening in C because, well, I understand what it is and what it is not. Sure, yeah, I program and have programmed in dozens of languages far more advanced than C, from C++ to APL, LISP, Python, Objective-C and others. And I have found that C --or the language-- is never the problem, it's the programmer that's the problem. I wonder how much energy the world wastes because of the overhead of "advanced" languages? There's a real cost to this in time, energy and resources. This reminds me of something completely unrelated to programming. On a visit to windmills in The Netherlands we noted that there were no safety barriers to the spinning gears within the windmill. In the US you would likely have lexan shields protecting people and kids from sticking their hands into a gear. In other parts of the world people are expected to be intelligent and responsible enough to understand the danger, not do stupid things and teach their children the same. Only one of those is a formula for breeding people who will not do dumb things. Stop trying to fix it. There's nothing wrong with it. Fix the software developer.
known 8y ago
Difference between Array and Linked List is enough to start confusion on pointers
- jibal 8y ago
  Say wut?
ufmace 8y ago
I haven't written much C, and I don't have a firm opinion on whether or not that particular issue is C's biggest mistake. I do think that just this one change sounds radical enough, as far as the effort it would take to convert existing C code that uses the high-risk pattern, that it seems better to just wholesale convert to a language that already mandates safety like Rust or Java. Particularly when you consider all of the other high-risk patterns in C that these other languages eliminate.
grrrrrrrrrrrrr 8y ago
"C retains the basic philosophy that programmers know what they are doing; it only requires that they state their intentions explicitly." The real 'mistake', is programmers not stating their intention explicitly.

260 points by etrevino 8y ago

rurban 8y ago

The mentioned Safe C Library is now at https://github.com/rurban/safeclib https://github.com/rurban/safeclib

pjmlp 8y ago
The problem with secure C11 Annex K functions, is that they are only secure in name. They are still as insecure as any traditional C string and memory function. Yes, they sorted out the issues about then a string always gets its null terminator. However given that buffer and size are still two different parameters, the issue of mixing up the values is still present.
- rurban 8y ago
  Nope. The buffer size is checked at compile-time. Much like glibc fortify, just better. There's no chance to mix them up. Even the spec'd unsafeties of the truncating n versions are fixed.
  - pjmlp 8y ago
    Can you please explain how strcpy_s() validates that dest actually points to a memory region with enough space for destsz bytes? https://en.cppreference.com/w/c/string/byte/strcpy https://en.cppreference.com/w/c/string/byte/strcpy

robert_foss 8y ago

Fair enough. Arrays losing dimensionality when passed through functions is a pain every now and then.

MrBingley 8y ago

I absolutely agree. Adding an array type to C that knows its own length would solve so many headaches, fix so many bugs, and prevent so many security vulnerabilities it's not even funny. Null terminated strings? Gone! Checked array indexing? Now possible! More efficient free that gets passed the array length? Now we could do it! The possibilities are incredible. Sadly, C is so obstinately stuck in its old ways that adding such a radical change will likely never happen. But one can dream ...

ars 8y ago
> But one can dream ... There's nothing stopping you from simply doing it. With a couple of macros the whole thing can just be a header file. True, it doesn't take you all the way there (you'll still need to manually check array access to make sure they don't go over), but it's a start. And those manual checks can be a macro as well, to make it easy to add them where needed.
- slededit 8y ago
  Malloc already includes a length and most arrays are heap based. I wish it could be exposed in a nice way. Of course it would have to support sub allocators or it wouldn't be C.
  - ric129 8y ago
    There's malloc_usable_size[1], assuming you mean asking the memory allocator what the array size is. But chances are that wouldn't work correctly, because what the amount of memory a malloc calls gives you and the amount you requested are often not the same. Modern memory allocators round up the request size to the nearest "size class". [1]: http://man7.org/linux/man-pages/man3/malloc_usable_size.3.html http://man7.org/linux/man-pages/man3/malloc_usable_size.3.ht...
webkike 8y ago
Adding anything to C is such a useless exercise because we've made so many advancements in plt since it's release we might as well make a new language.

earenndil 8y ago

> Notable among these are C++, the D programming language, and most recently, Go I would remove go from that list, and add rust and zig.

dosshell 8y ago
This was written in 2009, didn't rust first appeared in 2010?
- lightgreen 8y ago
  Why was it posted now without a year in square brackets? That was misleading.
  - jibal 8y ago
    The year is in parentheses in the title, and of course it's in the article. I for one have learned to always look at the date something was written. It irks me that there are so many web pages with time-relevant content that contain no date.

Drdrdrq 8y ago

Meh. What do you do with the dynamically allocated arrays then? Do you pass their dimensions alongside pointer? If that bothers you so much, you can create a struct that holds the pointer and metadata, and do the checks yourself. Calling this "C's biggest mistake" is a bit sensationalistic. EDIT: besides, you should start new projects in Rust anyway, because it takes security to whole other level. C did a great job, but it's a bit old. :)

adamnemecek 8y ago
The pattern is very present in all c code and rolling your own just causes paid when interacting with 3rd party code.
PeCaN 8y ago
>besides, you should start new projects in Rust anyway Thanks, I almost forgot what website I was on for a second.
- deleted 8y ago
  [deleted]
- Drdrdrq 8y ago
  No problem - happened to me 6 hours ago too. </s>
int_19h 8y ago
> Do you pass their dimensions alongside pointer That is literally the meaning of "fat pointer", and the linked article even explains it.
jibal 8y ago
The article explains why it's C's biggest mistke, and neither your nor anyone else has refuted it ... in fact, you don't even touch on it.

User23 8y ago

This is a very good article that highlights the importance of semantics.

WalterBright 8y ago

Apparently someone posted this here because of my remark:https://www.reddit.com/r/programming/comments/90ov9i/a_response_to_a_comment_on_the_riscv_isadev_list/e2thyts/ https://www.reddit.com/r/programming/comments/90ov9i/a_respo... Nice to see it get such a nice response!

altrego99 8y ago

Agree that this is a problem (if the programmer is not careful). But serious question, why even bother with this one fix? The only reason for the fix is so to make it more difficult to make errors. Fix arrays, then you would fix null pointer, then you might add objects, templating/generics to support a good collections library, rtti, and before you know it you are creating another one of c++, D, go, java. And we already have those. C paved the way. Why not let it be the end of it?

WalterBright 8y ago
Because buffer overflows are probably the number 1 security bug in C programs.
- ahmedalsudani 8y ago
  I was wondering why you were championing this idea and agreeing with the posted link in almost every way. Then I went back to the link and figured it out :) P.S. thank you for everything you have done with D. I read in another HN thread about Better C, and it convinced me that D is the language I should be investing my time in learning and using.
  - bachmeier 8y ago
    > I read in another HN thread about Better C A good tool to check out, but which hasn't been promoted much because it's new, is dpp[1]. You can directly reference C header files in your D code. With that, betterC mode becomes a viable option for adding to an existing C project. [1] https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
pjmlp 8y ago
Paved the way for what? Mainstream security exploits? There were OSes being written in better languages outside Bell Labs, had it been allowed to sell UNIX instead of giving it away for a symbolic price to universities, and the historical outcome would have been completely different.

bluetomcat 8y ago

Quite surprised to see this not mentioned. C99 allows you to use the "static" keyword in array function parameters like this: void foo(int arr[static 10]); It cannot check whether a passed pointer will point to enough space, but the compiler can warn you if you pass a fixed-size array of a smaller size.

WalterBright 8y ago
Dynamic arrays are far, far more common than static ones.
- bluetomcat 8y ago
  I beg to differ. In C especially, static arrays are quite common as struct members and as static objects at file scope, because dynamic allocations are a pain to manage and unnecessary when the maximum expected size is reasonably small. When the size of such arrays is computed at compile-time via macro definitions, that feature is quite handy.
  - WalterBright 8y ago
    > when the maximum expected size I pretty much never use static arrays because if I do I always without fail get a bug report when some user exceeds it.
  - jibal 8y ago
    "In C especially, static arrays are quite common as struct members and as static objects at file scope" Not among good programmers (unless the array is immutable).

drfuchs 8y ago

The proposal here is way too vague. And if you flesh it out, things start to fall apart: If nul-termination of strings is gone, does that mean that the fat pointers need to be three words long, so they have a "capacity" as well as a "current length"? If not, how do you manage to get string variable on the stack if its length might change? Or in a struct? How does concatenation work such that you can avoid horrible performance (think Java's String vs. StringBuffer)? On the other hand, if the fat pointers have a length and capacity, how do I get a fat pointer to a substring that's in the middle of a given string? Similar questions apply to general arrays, as well. Also: Am I able to take the address of an element of an array? Will that be a fat pointer too? How about a pointer to a sequence of elements? Can I do arithmetic on these pointers? If not, am I forced to pass around fat array pointers as well as index values when I want to call functions to operate on pieces of the array? How would you write Quicksort? Heapsort? And this doesn't even start to address questions like "how can I write an arena-allocation scheme when I need one"? In short, the reason that this sort of thing hasn't appeared in C is not because nobody has thought about it, nor because the C folks are too hide-bound to accept a good idea, but rather because it's not clear that there's a real, workable, limited, concise, solution that doesn't warp the language far off into Java/C#-land. It would be great if there were, but this isn't it.

WalterBright 8y ago
I happened to know the idea does work, and has been working in D for 18 years now. > If nul-termination of strings is gone, does that mean that the fat pointers need to be three words long, so they have a "capacity" as well as a "current length"? No. You'll still have the same issues with how memory is allocated and resized. But, once the memory is allocated, you have a safe and reliable way to access the memory without buffer overflows. > If not, how do you manage to get string variable on the stack if its length might change? Or in a struct? How does concatenation work such that you can avoid horrible performance (think Java's String vs. StringBuffer)? As I mentioned, it does not address allocating memory. However, it does offer one performance advantage in not having to call strlen to determine the size of the data. > On the other hand, if the fat pointers have a length and capacity, how do I get a fat pointer to a substring that's in the middle of a given string? In D, we call those slices. They look like this: T[] array = ... T[] slice = array[lower .. upper]; The compiler can insert checks that the slice[] lies within the bounds of array[]. > Am I able to take the address of an element of an array? Yes: `T* p = &array[3];` > Will that be a fat pointer too? No, it'll be regular pointer. To get a fat pointer, i.e. a slice: slice = array[lower .. upper]; > How about a pointer to a sequence of elements? Not sure what you mean. You can get a pointer or a slice of a dynamic array. > Can I do arithmetic on these pointers? Yes, via the slice method outlined above. > If not, am I forced to pass around fat array pointers as well as index values when I want to call functions to operate on pieces of the array? No, just the slice. > How would you write Quicksort? Heapsort? Show me your pointer version and I'll show you an array version. > And this doesn't even start to address questions like "how can I write an arena-allocation scheme when I need one"? The arena will likely be an array, right? Then return slices of it.

analognoise 8y ago

Fat Pointers - Pascal has had them since I think the beginning? So...30+ years later, we decide Pascal was right. Just saying. Shoutout to FreePascal/Lazarus!

WalterBright 8y ago
In Pascal, every array with a different dimension was a different type.
- clouddrover 8y ago
  That was true in the past, but Pascal has had dynamic arrays for over twenty years. The current versions of Free Pascal and Delphi are nice to use.
  - WalterBright 8y ago
    I kinda gave up on Pascal 35 years ago when I picked up a copy of K+R :-) The only thing I really liked from Pascal were the nested functions, which I put in D.
- pjmlp 8y ago
  That was already sorted out in early 80's Pascal dialects, even ISO Extended Pascal included support for it.
TimJYoung 8y ago
I keep reading articles like this on HN, and coming to the same conclusions as yourself over and over: why isn't Object Pascal more popular ? It solves many issues that have presented themselves over the last decade or so in various, more-popular languages, without any major downsides. I'm talking the language here - the RTL/system libraries and ecosystem is something that I think solves itself once more people start using the language. Is it really just about the issues with begin..end and verbosity ???
- analognoise 8y ago

Animats 8y ago

Yes, that's C's biggest mistake. (But remember, they had to cram the compiler into a 16-bit machine.) No, "fat pointers" are not a backwards-compatible solution. They've been tried. They were a feature of GCC at one time, used by almost nobody. I once had a proposal on this. See [1]. Enough people looked it over to find errors; this is version 3. The consensus is that it would work technically but not politically. The basic idea is that the programmer knows how big the array is; they just don't have a way to tell the compiler what expression defines the length of the array. Instead of int read(int fd, char buf[], size_t n); you write int read(int n; int fd, char (&buf)[n], size_t n); It generates the same calling sequence. Arrays are still passed as plain pointers. But the compiler now knows how big "buf" is, both on the caller and callee side, and can check. I also proposed adding slice syntax to C, so, when you want to talk about part of an array, you do it as a slice, not via pointer arithmetic. The key idea here is that you can call old code from new ("strict") code, and strict code from old code. When you get to all strict code, subscript errors should be all checkable. [1] http://www.animats.com/papers/languages/safearraysforc43.pdf http://www.animats.com/papers/languages/safearraysforc43.pdf

WalterBright 8y ago
I suspect that the reason your idea was not adopted was the syntax. It's not a phat pointer, it's two arguments with some rather complex syntax to connect the two. The reason I'm fairly confident of that assessment is I've had similar experiences with D when the syntax for something was too complex. Early on, the syntax for lambdas was rather clunkly. Everyone either hated it, or insisted that D didn't even have lambdas. Greatly simplifying the syntax was a revelation, suddenly D had lambdas and they became used everywhere. Syntax matters a great deal.
- Animats 8y ago
  Yes. int read(int n; int fd, char (&buf)[n], size_t n); is a bit bulky. The initial "int n;" is a little used GCC extension. Allowing int read(int fd, char (&buf)[n], size_t n); is an option. "n" is used before it is declared, which is strange for C. This is only a problem because of the UNIX idiom that buffer pointer comes before size in most system calls. char (&buf)[n] is also a bit bulky, but that, too, is forced by C/C++ tradition. char &buf[n] would be an array of refs, and char buf[n] would be an array passed by copy. There have been many, many attempts to "fix" C in a non-backwards compatible way. The result is always a new language. It's the backwards compatibility that's hard.

Annatar 8y ago

I don’t understand what the hoopla is about: in assembler we deal with arrays by having to know the size of each field without giving it a second thought. The solution is to learn assembler first, then move on to C. And AWK, as the next generation C doesn’t have this problem, or any of the C problems.

WalterBright 8y ago
I've written a lot of assembler code (including Empire in 100% assembler https://github.com/DigitalMars/Empire-for-PDP-11 https://github.com/DigitalMars/Empire-for-PDP-11) Assembler programs are very tedious to write, and so they tend to be rather small. You don't get any help from the non-existent compiler for even simple HLL features like static type checking.
- Annatar 8y ago
  As a demo scene coder, I have to disagree vehemently: assembler is a joy to write, at least on MC68000 and 6502 (Amiga and C=64). The only reason why I don’t write code in assembler but in C on UNIX is becuase of portability. To me, C is nothing more than a portable assembler with the extra unnecessary code because of the inefficiencies of optimizing compilers.
pjmlp 8y ago
There are quite a few reasons why using Assembly in 2018 is very niche.
- Annatar 8y ago
  What exactly are the arguments for that statement?
  - pjmlp 8y ago
    In the age of IoT and distributed computing we need portability, Assembly is the opposite of that. For stuff like SIMD we have compiler intrisics, loop vectorization and compute shaders. Even when writing straight Assembly, unless we are talking about a PIC class processor, the amount of opcodes and their behaviors across a CPU family are so broad no human manages to fit the instruction manuals on their head, several thousand pages long. Modern CPUs, aren't a Z80 on a Speccy where we could fit the opcodes and memory map on our head. So it is constrained to things like a few hundred KB PICs, people writing compiler backends, software decoding for video/audio codecs or kernel level drivers, a very specialized set of tasks, the very definition of niche.

speedplane 8y ago

Gimme a break, making stricter requirements on C arrays may theoretically make some things easier, but we’re talking 1% improvement. What makes C hard (and great) is requiring an understanding of not just memory, but memory allocation and deallocation schemes. For many beginners this is hard conceptually, but for everyone, keeping track of allocated and unallocated memory is extremely difficult.

WalterBright 8y ago
My proposal is purely additive, you won't need to use it at all if you don't want to. But I suspect you'll gravitate towards it over time, most everyone does (experience with D dynamic arrays).
mankash666 8y ago
Disagree. C was the first language I/we learnt, and it's still my favorite. It's a bit like the first language you learn. For someone from the Latin family of languages, Mandarin's verbal & written structure might seem hard, but for native Chinese, it's second nature.
- speedplane 8y ago
  Mandarin may be your first and favorite, but that doesn't make it easy to learn. Same with C.

nurettin 8y ago

Fat pointers manifested themselves in Pascal as strings and are still being used in modern Delphi.

chmike 8y ago

From my experience Go's array (slice) is a far better solution. It does not only carry the size (number of elements), it also carries the array buffer capacity. To me it's the epitome of what arrays should be.

zaphirplane 8y ago
Usually people have to refer to a slice cheat sheet to work with it, perhaps it’s not an intuitive concept/api
- burntsushi 8y ago
  That's because of a lack of named methods to perform common operations. It has nothing to do with the fact that slices are fat pointers. Also, nobody I know constantly looks at a cheat sheet. The concepts motivating the various slice transformations get ingrained pretty quickly.

deleted 8y ago

[deleted]

kyberias 8y ago

Why does the author of D want to "fix" C by changing it into D? Concentrate on that D language.

alphaglosined 8y ago
You see, before D ever existed, Walter wrote a C/C++ compiler professionally. That is why he would like to see C improved. He has just as much interest in seeing it improved as you or I do. In fact, I would say he has more reason as he has dedicated a good part of his life towards it...
WalterBright 8y ago
I like to fix things. Why not share a simple and effective fix?
- kyberias 8y ago
  Isn't there a standards organization / body for C language. Have you proposed this there? What was the outcome?
pjmlp 8y ago
Because it is clear to us, advocates of safer systems programming languages, that no one is going to rewrite POSIX based platforms in something else. So we would like to improve our foundations, to move UNIX derived OSes to some kind of safer C, instead of having it be the backdoor of the whole security infrastructure.
jibal 8y ago
> Why does the author of D want to "fix" C What's the downside? > by changing it into D? That comment is tendentious, hyperbolic, and generally credibility-damaging. > Concentrate on that D language. You think he doesn't?

okket 8y ago

(2009) See also discussion from 9 years ago: https://news.ycombinator.com/item?id=1014533 https://news.ycombinator.com/item?id=1014533 (47 comments)

auslander 8y ago

OpenBSD replaced strcat by strlcat, strcpy by strlcpy 20 years ago, in OpenBSD 2.4. They are implemented in the C libraries for OpenBSD, FreeBSD, NetBSD, Solaris, OS X, and QNX. They have not been included in the GNU C library used by Linux.

medecau 8y ago
A few years ago I remember seeing strl* mentioned in a slide presentation for something that must have come from the oBSD camp. Since then I thought, not knowing any amount of C, that strl* was part of the language and available to all. Imagine if you will my confusion everytime I read people complaining about C being insecure. Your comment corrected my perception of this. Thank you.
- auslander 8y ago
  I admire the no-nonsense approach by OpenBSD: "The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better." https://www.openbsd.org/security.html https://www.openbsd.org/security.html I'm in DevOps field, and this 'make it right from the start' resonates strongly with me. Richard Feynman: Disregard others :)
WalterBright 8y ago
Those functions have a separate length parameter. There is no way to mechanically check that the length argument accurately reflects the length of the string. It's not an effective solution.
- pjmlp 8y ago
  Which is the reason why I consider the C11 security annex, anything but safe.
- auslander 8y ago

hota_mazi 8y ago

Conflating pointers and arrays seem pretty minor and not the cause for many bugs. The main source of bugs in C to me would be pointer arithmetics.

WalterBright 8y ago
Pointer arithmetic is mainly used to access arrays, and is where the buffer overflows come from. Using actual arrays instead allows the compiler to insert overflow checking code.

nearmuse 8y ago

What's the mistake? You pass a pointer and the number of elements, it's just the C way. At any point in time you have to pay attention. What is the proposal here? Make all arrays structures? Or add some weird un-C syntactic sugar?

SamReidHughes 8y ago
It's a question of priorities. It depends whether your goal is to maximize productivity and minimize the defect rate, or if your goal is to tell people they need to pay attention.
jibal 8y ago
"What is the proposal here?" You're commenting without reading the article?

IshKebab 8y ago

I feel like Sibiu should just write a new language that is C with fixes, and no more.

pjmlp 8y ago
Has been tried a couple of times, the problem is mostly human not technical.

the_duke 8y ago

Should have a 2009 in the title.

xroche 8y ago

This is IMHO by far NOT C' biggest mistake. Not even close. A typical compiler will even warn you when you do something stupid with arrays in function definitions (-Wsizeof-array-argument is the default nowadays). On the other hand, UBE (undefined, or unspecified behavior) are probably the nastiest stuff that can bite you in C. I have been programming in C for a very, very long time, and I am still getting hit by UBE time to time, because, eh, you tend to forget "this case". Last time, it took me a while to realize the bug in the following code snippet from a colleague (not the actual code, but the idea is there): struct ip_weight { in_addr_t ip; uint64_t weight; }; const struct ip_weight ipw1 = {0x7F000001, 1}; const struct ip_weight ipw2 = {0x7F000001, 1}; const uint32_t hash1 = hash_function(&ipw1, sizeof(ipw1)); const uint32_t hash2 = hash_function(&ipw2, sizeof(ipw2)); The bug: hash1 and hash2 are not the same. For those who are fluent in C UBE, this is obvious, and you'll probably smile. But even for veterans, you tend to miss that after a long day of work. This, my friends, is part of the real mistakes in C: leaving too many UBE. The result is coding in a minefield. [You probably found the bug, right ? If not: the obvious issue is that 'struct ip_weight' needs padding for the second field. And while all omitted fields are by the standard initialized to 0 when you declare a structure on the stack, padding value is undefined; and gcc typically leave padding with stack dirty content.]

senatorobama 8y ago
Why is struct ip_weight padded.. is it to make it word aligned on 64-bit platforms?
- blattimwind 8y ago
  in_addr_t is a 32 bit integer. On 64 bit archs this will usually result in a 32 bit padding for word alignment.
  - deleted 8y ago
    [deleted]
- pandaman 8y ago
  To align 'weight' member on its size.

toolslive 8y ago

Isn't the fact that core types don't have a fixed representation a bigger mistake ? a char can be 16 bits, for example, aso.

WalterBright 8y ago
The unfixed type sizes are mostly just a nuisance, though I've wasted a lot of time dealing with them.
- p0nce 8y ago
  It can also create untold naming conflicts.
flingo 8y ago
When can a char be 16 bits? I presume it'd still have a sizeof() of 1 though.
- toolslive 8y ago
  Texas Instruments C54x DSPs It can even be funkier, like 12 bits in a char https://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char https://stackoverflow.com/questions/2098149/what-platforms-h... It's a mess
- WalterBright 8y ago
  I've seen 32 bit chars on some DSP C implementations.
- jibal 8y ago
  "When can a char be 16 bits?" Whenever an implementation says so. There are now few machines where the addressable unit is not 8 bits though, which is why languages like D and Java can get away with not supporting them. > I presume it'd still have a sizeof() of 1 though. The language standard requires that.
hcs 8y ago
Also char not specified in the language as signed or unsigned...

xaduha 8y ago

That's why I hope Red/System and just Red in general takes off https://static.red-lang.org/red-system-specs.html https://static.red-lang.org/red-system-specs.html

WalterBright 8y ago

Just for fun, type in this program: int fred(int a[10]) { return a[11]; } It compiles without error with gcc and clang, even with -Wall. The code generated by clang is: mov EAX,02Ch[RDI] ret i.e. buffer overflow, even though the array size is given. Compile the equivalent DasBetterC program: int fred(ref int[10] a) { return a[11]; } fred.d(2): Error: array index 11 is out of bounds a[0 .. 10] And the 32 bit code generated (when using 9 instead of 11 so it will compile): mov EAX,024h[EAX] ret

bluecalm 8y ago

Why is this such a serious issue? I mean it is inconvenient to always pass length along with the pointer but it's not that inconvenient. It's a bit more typing but that's where problems end.

apz28 8y ago

I would love one day that programming should adhere to the discipline as in bridge/car safety. Simple malpractice will go to jail for it then there will be no argumment/discussion about this stupid mistake that can be verified by tool Cheers Pham

flingo 8y ago

Is it better to pass the length of the array, or a pointer to the last valid address in the array? (or one past that) There's probably an advantage in the two types being the same. Thought of this as I was reading the article.

jibal 8y ago
The length is better, since that's almost always what you want. > There's probably an advantage in the two types being the same. Not really.

rebootthesystem 8y ago

My guess is this won't be a popular post given the average age of HN participants. There's nothing whatsoever wrong with C. The problem are programmers who grew up completely and utterly disconnected from the machine. I am from that generation that actually did useful things with machine language. I said "machine language" not "assembler". Yes, I am one of those guys who actually programmed IMSAI era machines using toggle switches. Thankfully not for long. There is no such thing as an "array". That's a human construct. All you have is some registers and a pile of memory with addresses to go store and retrieve things from it. That's it. That is the entire reality of computing. And so, you can choose to be a knowledgeable software developer and be keenly aware of what the words you type on your screen actually do or you can live in ignorance of this and perennially think things are broken. In C you are responsible for understanding that you are not typing magical words that solve all your problems. You are in charge. An array, as such, is just the address of the starting point of some bunch of numbers you are storing in a chunk of memory. Done. Period. Past that, one can choose to understand and work with this or saddle a language with all kinds of additional code that removes the programmer from the responsibility of knowing what's going on at the expense of having to execute TONS of UNNECESSARY code every single time one wants to do anything at all. An array ceases to be a chunk-o-data and becomes that plus a bunch of other stuff in memory which, in turn, relies on a pile of code that wraps it into something that a programmer can use without much thought given. This is how, for example, coding something like a Genetic Algorithm in Objective-C can be hundreds of times slower than re-coding it in C (or C++), where you actually have to mind what you are doing. To me that's just laziness. Or lack of education. Or both. I have never, ever, had any issues with magical things happening in C because, well, I understand what it is and what it is not. Sure, yeah, I program and have programmed in dozens of languages far more advanced than C, from C++ to APL, LISP, Python, Objective-C and others. And I have found that C --or the language-- is never the problem, it's the programmer that's the problem. I wonder how much energy the world wastes because of the overhead of "advanced" languages? There's a real cost to this in time, energy and resources. This reminds me of something completely unrelated to programming. On a visit to windmills in The Netherlands we noted that there were no safety barriers to the spinning gears within the windmill. In the US you would likely have lexan shields protecting people and kids from sticking their hands into a gear. In other parts of the world people are expected to be intelligent and responsible enough to understand the danger, not do stupid things and teach their children the same. Only one of those is a formula for breeding people who will not do dumb things. Stop trying to fix it. There's nothing wrong with it. Fix the software developer.

known 8y ago

Difference between Array and Linked List is enough to start confusion on pointers

jibal 8y ago
Say wut?

ufmace 8y ago

I haven't written much C, and I don't have a firm opinion on whether or not that particular issue is C's biggest mistake. I do think that just this one change sounds radical enough, as far as the effort it would take to convert existing C code that uses the high-risk pattern, that it seems better to just wholesale convert to a language that already mandates safety like Rust or Java. Particularly when you consider all of the other high-risk patterns in C that these other languages eliminate.

grrrrrrrrrrrrr 8y ago

"C retains the basic philosophy that programmers know what they are doing; it only requires that they state their intentions explicitly." The real 'mistake', is programmers not stating their intention explicitly.