Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C’s Biggest Mistake (2009)

digitalmars.com

Post reply on HN
Print view View original

61–70 of 382 posts

Re: C’s Biggest Mistake (2009)

#61

Post by quelsolaar »

dependenttypes wrote: post #56
quelsolaar wrote: post #53

Personally I like it the way it is. If you want to copy an array when making a function call you can define a struct with a array in it, and pas the structure. If C did pass array lengths it still wouldn't matter since C doesn't (and in my opinion shouldn't) check for overflows.

> since C doesn't ... check for overflows Because it's a language, not an implementation. An implementation is free to do so (and there are such implementations after all).

That's correct! C doesn't require checking for overflows, but it also doesn't forbid implementations from doing so. both are features.

Re: C’s Biggest Mistake (2009)

#62

Post by dependenttypes »

david2ndaccount wrote: post #13

In C you can declare pointers to arrays, the syntax is just somewhat strange. You can even declare it as a pointer to a variable sized array with c99, eg: void foo(size_t length, char (*x)[length]){ size_t size = sizeof(*x); assert(size == length); printf("sizeof(*x): %zu\n", sizeof(*x)); }

Here is a post from 2014 from someone who is in the C standard committee. https://gustedt.wordpress.com/2014/09/08/dont-use-fake-matri...

Re: C’s Biggest Mistake (2009)

#63

Post by true_religion »

leetcrew wrote: post #46
eps wrote: post #35

Earlier quoted context omitted.

I'm not sure whom this proposal is aimed at exactly. Any production-quality C code will already use a (pointer + count) combo when passing arrays to a function, which is something that will still be needed under your proposal because the vast majority of arrays is dynamically sized. So unless all arrays in C are given the fat pointer treatment, I don't really see how what you suggest would make much of a difference.…

pointer + size does not really fix anything, as you are relying on the programmer to correctly keep track of the size. I'm not even sure what alternative this improves upon. even more error-prone null value marking the end? praying the array will be big enough (looking at you, gets!)? unless you have a team of incredibly diligent coders, people are going to read past the end of bare arrays over and over again. one sp…

Would you just wrap the pointer and size in a strut, then only iterate the array via a library of functions that check the size first?

I don't code c full time, but it's what I have always done when needing to use c via ffi to get a speed up in a dynamic language.

Re: C’s Biggest Mistake (2009)

#64

Post by WalterBright »

Something1234 wrote: post #50

Stupid question, but how do I access the size of an array using this fancy new declaration if it were to be added? It doesn't seem like any sugar is there to provide "range based for loops." Wait I would just use `sizeof` but then I'm still doing pointer math then?

A macro can be added to access the length property.

Re: C’s Biggest Mistake (2009)

#65

Post by viraptor »

teej wrote: post #54
Upvoter33 wrote: post #49

Earlier quoted context omitted.

"C is finished if it doesn't address the buffer overflow problem" You should keep making this prediction ... one day you might be right! :)

C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening.

I love the move to d/rust/zig/nim/... but there are other issues too. Ecosystem of libraries, stabilisation of common patterns (futures and Tokio issues are still out there), platform compatibilities, industry support for moving away from known solutions, and many other issues. Even if we all suddenly knew Rust perfectly tomorrow, there are other issues in the way.

Re: C’s Biggest Mistake (2009)

#66

Post by Koshkin »

WalterBright wrote: post #30
rightbyte wrote: post #24

Earlier quoted context omitted.

The proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

In my experience with language design, a little bit of syntactic sugar can have transformative results. C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.

I wonder if a better idea (in principle) would be to have some kind of hardware implementation, sort of like a finer-grained memory segmentation.

Re: C’s Biggest Mistake (2009)

#67

Post by unsatchmo »

non-entity wrote: post #39
baby wrote: post #17

Earlier quoted context omitted.

I don't see a future where C survives, not only because of memory corruption bugs (although that's a pretty big one), but also for usability: the lack of package manager, common build system, good documentation, good standard library, etc. are just too much to compete with any modern system language.

As much as I dislike C > There are only two kinds of languages: the ones people complain about and the ones nobody uses. This unfortunately seems to mostly hold true.

Porque no los dos? There are a few languages that nobody uses and also everybody seems to complain about.

Re: C’s Biggest Mistake (2009)

#68

Post by rightbyte »

quelsolaar wrote: post #57
franciscop wrote: post #52

This was probably the most confusing thing about C when I first started learning programming back in the day. When you call a function you pass the value, except in arrays where it gets converted as a pointer. It was explained back then to me that the reason is because copying the whole array was not efficient so it was better to pass the reference.

I think a better way to think about is to say that when you type: int a[10]; you allocate 10 integers and "a" is the pointer to the first one of them. Arrays are just memory, just like what you get wen calling malloc, and memory is accessed using pointers in C.

That mindset doesn't cover sizeof(a) properly.

Re: C’s Biggest Mistake (2009)

#69

Post by fizixer »

xxpor wrote: post #37
enriquto wrote: post #31

Earlier quoted context omitted.

The real troubles are undefined behavior and aliasing. Buffer overflows are just a well known gimmick of the language that is more or less controllable with some discipline. Aliasing is hell. You cannot even use a global variable safely!

Isn't that what asan/ubsan is for? Granted, it's not static analysis, but it should catch most aliasing related errors, no?

I'm fully in the camp of C plus powerful analysis tools, plus a high-level language (Python or Scheme).

Re: C’s Biggest Mistake (2009)

#70

Post by skywhopper »

It’s not a “mistake”. This article is complaining about a misinterpretation of C’s functionality. Arrays are not “real” data structures in C: there’s no such thing. The array-ish syntax that’s available is just a some syntactic sugar on top of pointers. You could say that having the sugar at all is a mistake. Or that C is incomplete without first-class array types. This is a cute hack, but at this point (far more than 10 years ago) it’s probably better to move on to Rust if you don’t like this aspect of C, rather than proposing to hack the language.
Post reply on HN