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

11–20 of 382 posts

Re: C’s Biggest Mistake (2009)

#11

Post by WalterBright »

antiquark wrote: post #6
bobbyi_settv wrote: post #3

Earlier quoted context omitted.

> There are performance critical paths where passing a size_t is just unnecessary You would still be able to declare your function as taking a pointer (instead of an array, which in this world would be a far pointer) if you need to He's saying to deprecate char[] as a parameter type, not char

An existing alternative is to put an array in a struct: struct string123 { char data[123]; }; Then create functions that user pointers to these string123 structs.

That does work, except for:

1. variable length buffers

2. every other piece of code you want to interface with uses `char*`

Re: C’s Biggest Mistake (2009)

#12

Post by nmarks100 »

WalterBright wrote: post #7
ktpsns wrote: post #2

I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…

The #1 undetected bug problem with C programs is buffer overflows. Experience shows it is extremely difficult to verify that arbitrary C code doesn't have buffer overflows in it. Assistance from the core language design can improve things a great deal. D allows passing both raw pointers as parameters and pointer/length pairs. It's up to the user to choose. In practice, people have simply moved away from using raw poi…

I don't agree that in the days of valgrind, asan etc. the #1 issue is buffer overflows.

#1 and #2 are integer overflows and aliasing mistakes.

Re: C’s Biggest Mistake (2009)

#13

Post by david2ndaccount »

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));
  }

Re: C’s Biggest Mistake (2009)

#14

Post by david2ndaccount »

antiquark wrote: post #6
bobbyi_settv wrote: post #3

Earlier quoted context omitted.

> There are performance critical paths where passing a size_t is just unnecessary You would still be able to declare your function as taking a pointer (instead of an array, which in this world would be a far pointer) if you need to He's saying to deprecate char[] as a parameter type, not char

An existing alternative is to put an array in a struct: struct string123 { char data[123]; }; Then create functions that user pointers to these string123 structs.

If you want a pointer to a fixed size array, just use one, eg

char (*data)[123]; // syntax is somewhat awkward

Re: C’s Biggest Mistake (2009)

#15

Post by WalterBright »

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.

Re: C’s Biggest Mistake (2009)

#16

Post by WalterBright »

nmarks100 wrote: post #12
WalterBright wrote: post #7

Earlier quoted context omitted.

The #1 undetected bug problem with C programs is buffer overflows. Experience shows it is extremely difficult to verify that arbitrary C code doesn't have buffer overflows in it. Assistance from the core language design can improve things a great deal. D allows passing both raw pointers as parameters and pointer/length pairs. It's up to the user to choose. In practice, people have simply moved away from using raw poi…

I don't agree that in the days of valgrind, asan etc. the #1 issue is buffer overflows. #1 and #2 are integer overflows and aliasing mistakes.

valgrind is a marvelous tool, but it only detects actual buffer overflows, not vulnerability to buffer overflows.

Re: C’s Biggest Mistake (2009)

#17

Post by baby »

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.

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.

Re: C’s Biggest Mistake (2009)

#18

Post by tgb »

bobbyi_settv wrote: post #3
ktpsns wrote: post #2

I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…

> There are performance critical paths where passing a size_t is just unnecessary You would still be able to declare your function as taking a pointer (instead of an array, which in this world would be a far pointer) if you need to He's saying to deprecate char[] as a parameter type, not char

Interestingly, I assume you meant to end your post with "pointer to char" not "char" itself, but asterix is the the italics formatting character on HN so it's italicized it. But the funny thing is that it's italicized the "reply" button (as well as an empty i-tag after "char").

Re: C’s Biggest Mistake (2009)

#20

Post by forrestthewoods »

baby wrote: post #17
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.

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.

> I don't see a future where C survives

if C dies then what replaces it?

Post reply on HN