News for hackers. Stuff that matters.
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by MrBingley on Sunday July 22, 2018 @02:13AM (#17585497)
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 ...
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by bluetomcat on Sunday July 22, 2018 @03:35AM (#17585685)
> Adding an array type to C that knows its own length would solve so many headaches

C arrays know their length, it's always `sizeof(arr) / sizeof(*arr)`. It's just that arrays become pointers when passed between functions, and dynamically-sized regions (what is an array in most other languages) are always accessed via a pointer.

Re:Conflating pointers with arrays: C's biggest mistake? (2009) by jibal on Monday July 23, 2018 @06:11AM (#17591700)
He said "array type". There isn't one in C.

"It's just that arrays become pointers when passed between functions"

Oh, is that all?

Did you read the article, or the comment you're responding to? They point out the cost of "just" doing that.

Re:Conflating pointers with arrays: C's biggest mistake? (2009) by m_mueller on Sunday July 22, 2018 @02:51AM (#17585571)
I’ll add to this that C having committed to this mistake is one of thr main reasons some people (scientific programmers) are still using Fortran. Arrays with dimensions, especially multidimensional ones, allow for a lot of syntactic sugar that are very useful, such as slicing.
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by geoalchimista on Sunday July 22, 2018 @04:54AM (#17585900)
Modern Fortran (90 to 2008) has evolved a lot regarding array arithmetic and broadcasting, yet still maintain backward compatibility. I don't think that couldn't be done in C, but as many has pointed out, the problem seems to be why bother when there are already C++/D/Java/C#/Go/Rust ...

However, I'd recommend people who deal heavily with multidimensional arrays but couldn't sacrifice the low-level C environment for a dynamic language to consider using the ISO_C_BINDING of Fortran 2003. It provides fully C compatible native types, and can be compiled together with C (you get gfortran from GCC anyway).

Re:Conflating pointers with arrays: C's biggest mistake? (2009) by macintux on Sunday July 22, 2018 @10:57PM (#17590274)
Without knowing Fortran, I’d speculate it’s easier to maintain backwards compatibility in a language that doesn’t have as direct a mapping to hardware as C. Fortran seems to have more abstractions built in.
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by geoalchimista on Monday July 23, 2018 @12:43PM (#17593909)
That's true. It predated C but even then abstracted the user away from the hardware (and still does). I wouldn't suggest any use of Fortran beyond number crunching and array arithmetic.
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by Athas on Sunday July 22, 2018 @04:11AM (#17585797)
Hell, you don't even have to go to slicing for language-supported multidimensional arrays to make sense. Simply being able to index with a[i][j] is so much nicer than the manual flat addressing a[i*n+j] that you end up with in C. (a[i][j] does work in C, but only if the array dimensions are constants.)
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by ars on Sunday July 22, 2018 @02:19AM (#17585509)
> 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.

Re:Conflating pointers with arrays: C's biggest mistake? (2009) by slededit on Sunday July 22, 2018 @02:25AM (#17585522)
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.
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by ric129 on Sunday July 22, 2018 @10:27AM (#17586917)
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.ht...

Re:Conflating pointers with arrays: C's biggest mistake? (2009) by kahlonel on Sunday July 22, 2018 @02:46AM (#17585562)
Its actually quite common for C programmers to create their own array type that knows its length, and use it in their projects. See this for example: https://github.com/antirez/sds
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by WalterBright on Sunday July 22, 2018 @03:16AM (#17585636)
Everybody writes their own string package for C. I've written probably a couple dozen of them. They're all inadequate for one reason or another, hence my subsequent attempts.

Probably the most damning problem is none of them are able to interoperate.

Re:Conflating pointers with arrays: C's biggest mistake? (2009) by webkike on Sunday July 22, 2018 @02:26AM (#17585524)
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.
Re:Conflating pointers with arrays: C's biggest mistake? (2009) by WalterBright on Sunday July 22, 2018 @03:16AM (#17585638)
Well, I did that, too :-)