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

91–100 of 382 posts

Re: C’s Biggest Mistake (2009)

#91

Post by quelsolaar »

Koshkin wrote: post #72
quelsolaar wrote: post #61

Earlier quoted context omitted.

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

I don’t think it is possible, not without changing some parts of the C’s specification. At the very least you’d need to be able to somehow encode the length of the buffer in the pointer to it. (There is no semantic difference between a pointer to a simple, fixed-length variable and a pointer to an array.)

You can keep a list of every allocation and every time the code does a memory read/write the implementation can look up to see if the pointer is within a valid allocation space. I have implemented some things like this: https://www.youtube.com/watch?v=pvkn9Xz-xks

Re: C’s Biggest Mistake (2009)

#92

Post by SV_BubbleTime »

rightbyte wrote: post #24
WalterBright wrote: post #15

Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.

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

Agreed. The proposal is also wasteful.

>extern void foo(size_t dim, char *a);

And the like assumes that I have the space to waste a native type on every array. So if I’m using a 10 length array, I need to provision a native 32 or 64 bit value for “10”.

In embedded system this wouldn’t happen. At least not mine, I’m running up on limits all over the place even being careful with bitfields and appropriately sized types.

He’s right of course that foo(array[]) is converted to a pointer but that’s why I think you should always use array as a pointer so YOU know not to rely on its automatic protections.

I get the point; but I just don’t see C making this change.

Re: C’s Biggest Mistake (2009)

#93

Post by asveikau »

rumanator wrote: post #75
WalterBright wrote: post #59

Earlier quoted context omitted.

I suspect C has been steadily losing ground since I made it.

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense. It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and ut…

Maybe people are voting this down because they think it's directed at Walter Bright in particular, but I think there is actually some truth in the harsh comment.

Nothing about Walter Bright in this statement, but some of the harshest criticisms from others I have seen of C are not from expert practitioners in C.

People who are experts and also critics seem to have a more practical, realistic, nuanced critique, that understands history and challenges to adoption, admits that the long history and difficulty of replacing C isn't exactly for no reason.

Re: C’s Biggest Mistake (2009)

#94

Post by pritovido »

I actually believe the way C works is great, as simple as it could be and it gives you power to do exactly what you want, they way you want it.

I would certainly hate(and would continue using them btw) that they remove normal pointers from C. It would be like removing s expressions from lisp.

I believe that the solution to this "mistake" is just not using c directly, using other languages to write C code for you, or use c primitives that are 100% well tested.

That is what we do, our c primitives-libraries-modules are written and tested by lisp and our own language.

It it then very easy to use that code in python or c++, swift or whatever as libraries or modules.

Re: C’s Biggest Mistake (2009)

#95

Post by colejohnson66 »

rowanG077 wrote: post #44
SamReidHughes wrote: post #5

The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.

I don't feel it's so bad. You have a a specific flag to tell the compiler to show warnings if you have any.

Why should I need to use a flag to fix something that doesn’t make sense? I can understand implicit up-conversions, but down-conversions too?

Re: C’s Biggest Mistake (2009)

#96

Post by FpUser »

WalterBright wrote: post #15

Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.

Pascal (Delphi and FreePascal incarnations) does that just fine with strings and dynamic arrays and in a way that is compatible with C. Just friggin' steal it an be done.

Re: C’s Biggest Mistake (2009)

#97

Post by FpUser »

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 used to write whole bunch of firmware for microcontrollers and frankly C was doing just fine for me in this area.

Re: C’s Biggest Mistake (2009)

#98

Post by johnisgood »

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.

One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way. The syntax is extremely simple, too, vs. Rust. Rust is close to Perl when it comes to syntax; full of symbols. Too implicit for me. I want to look at the code, and I want to understand what the heck is going on, even if it is written by someone else. I usually do, with C. Rust? Not so much, and believe me, I tried. I would not like to call myself an idiot, either. :)

A viable C replacement is Ada, although it is not for people who dislike the "code is documentation" bit.

Re: C’s Biggest Mistake (2009)

#99

Post by torstenvl »

SV_BubbleTime wrote: post #92
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.

Agreed. The proposal is also wasteful. >extern void foo(size_t dim, char *a); And the like assumes that I have the space to waste a native type on every array. So if I’m using a 10 length array, I need to provision a native 32 or 64 bit value for “10”. In embedded system this wouldn’t happen. At least not mine, I’m running up on limits all over the place even being careful with bitfields and appropriately sized types…

So... don't use array syntax in the function prototype and definition? The proposal doesn't PROHIBIT passing a pointer, it would just offer an option to pass a fat array.

Re: C’s Biggest Mistake (2009)

#100

Post by leetcrew »

true_religion wrote: post #63
leetcrew wrote: post #46

Earlier quoted context omitted.

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.

you could do that, if you were using a library that provided/understood that struct. not sure how common this is; I work with c++ much more than c.

the problem with this approach is that you are still relying on the application programmer to provide the correct size at the beginning and not to mess it up by directly accessing the struct member later. private/public does not really exist in c, so it is a lot harder to enforce invariants within an object. the library could make the struct layout a private implementation detail (ie, not fully define the struct in the header provided to the client and take a pointer to the struct as arguments in the API) to at least discourage this. you could combine this approach with a my_array_struct_init function that returns a pointer to an empty array object. this is a common approach taken in c libraries (eg, libcurl) where the author really doesn't want you messing with their structs.

Post reply on HN