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

291–300 of 382 posts

Re: C’s Biggest Mistake (2009)

#291

Post by knaq »

saagarjha wrote: post #280
knaq wrote: post #211

Earlier quoted context omitted.

I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy) Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually wan…

> Are we having huge problems with structs being passed by value? Doing this frequently in any application means your profile will have a lot of memcpy in it.

Yes, but is that happening? I think the answer is no. The mere ability to pass huge structures does not cause programmers to do that.

I believe the same would be true if the language allowed passing arrays. Programmers would not generally pass them around. There is no need for the language to protect us from this by failing to implement the ability to pass arrays.

Re: C’s Biggest Mistake (2009)

#292

Post by throwaway_pdp09 »

WalterBright wrote: post #59
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! :)

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

"you suspect" is pretty vacuous.

More usefully, if you want people to use D instead, what is stopping them, what reasons do they give? How can these be mitigated, cos while I like C I sure would like something better.

Re: C’s Biggest Mistake (2009)

#293

Post by harry8 » 

    typedef struct fat_ptr_t {
        size_t size;
        void * start;
    } fat_ptr_t;

    extern void foo(fat_ptr_t a);
if it's a good idea to use a fat pointer, why do we need new syntax to sell it? What am I missing here?

Re: C’s Biggest Mistake (2009)

#294

Post by saagarjha »

knaq wrote: post #291
saagarjha wrote: post #280

Earlier quoted context omitted.

> Are we having huge problems with structs being passed by value? Doing this frequently in any application means your profile will have a lot of memcpy in it.

Yes, but is that happening? I think the answer is no. The mere ability to pass huge structures does not cause programmers to do that. I believe the same would be true if the language allowed passing arrays. Programmers would not generally pass them around. There is no need for the language to protect us from this by failing to implement the ability to pass arrays.

I think I agree with that position. I seem to have gotten the impression that you were doing this and not seeing a performance impact, which has been wrong in my experience.

Re: C’s Biggest Mistake (2009)

#295

Post by jstimpfle »

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 must be a really really good programmer, since I rarely see the need to use strlen().

For one, strings are just chunks of memory like other arrays. So for almost any string that is not a literal in the source code, you just store offset/length as needed, like for any other array. I have sizeable projects (on the order of 10K lines) that have maybe 0 or 1 instances of strlen() in the code.

Very often though, strings are bounded and pretty short (since they are meant for human consumption), and in these cases, using strlen() when looking up a string is often sensible, since persisting the length might require more memory than the string itself.

Another case is when you're scanning the string from left to right anyway, so you just "stream" through it until you find the terminating 0. That's how printf() and friends work (they take a formatting string), and arguably this scheme works just fine.

Btw, the length of a string literal is (sizeof "Hello" - 1). You can also initialize char arrays using string literals and have the size available:

    static const char name[] = "Foobar";
    static const int nameLen = sizeof name - 1;

Re: C’s Biggest Mistake (2009)

#296

Post by MaxBarraclough »

saagarjha wrote: post #282
MaxBarraclough wrote: post #136

Earlier quoted context omitted.

> C++ gives you more tools for avoiding them A direct link, for the curious: https://en.cppreference.com/w/cpp/container/array As an aside, the C’s Biggest Mistake article cropped up in HN discussion 8 days ago, https://news.ycombinator.com/item?id=24373728

C++ also lets you grab an array’s size via templates, FWIW.

Do you mean std::extent? [0] You can do the same in C if you define a macro that uses sizeof [1]

This doesn't diminish the advantage of std::array, though, as it embeds the size of the array into the object, unlike when a raw array is passed and 'decays' to a pointer.

[0] https://en.cppreference.com/w/cpp/types/extent

[1] https://stackoverflow.com/a/4415646/

Re: C’s Biggest Mistake (2009)

#297

Post by saagarjha »

pjmlp wrote: post #283
saagarjha wrote: post #274

Earlier quoted context omitted.

You bring this up often and I ask you to modify your wording about every time I see it. Android will not require these extensions, no hardware ships with it yet. Android says they will support it.

And I give you the official wording of Google every time. > Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem. Based on the current data points, MTE provides tremendous benefits at acceptable performance costs. We are con…

I am not sure if I have made myself clear, because I have no issues with the Google documents on this and I believe they are very clear: this feature is optional! Optional optional optional, only on hardware that supports it will Google implement these things because they literally cannot use it otherwise. Your wording has always implied that this is a requirement to run Android 11 and it is not, and that is what I am asking you to change. Like, what’s wrong with being accurate and saying “Google is implementing support for this in Android 11”? “This feature may be used to classify Android devices”?

Re: C’s Biggest Mistake (2009)

#298

Post by saagarjha »

MaxBarraclough wrote: post #296
saagarjha wrote: post #282

Earlier quoted context omitted.

C++ also lets you grab an array’s size via templates, FWIW.

Do you mean std::extent ? [0] You can do the same in C if you define a macro that uses sizeof [1] This doesn't diminish the advantage of std::array , though, as it embeds the size of the array into the object, unlike when a raw array is passed and 'decays' to a pointer. [0] https://en.cppreference.com/w/cpp/types/extent [1] https://stackoverflow.com/a/4415646/

I mean like you can pass it through a function by using the “array syntax” when defining the parameter and making the size a template parameter. Like so:

  template 
  void foo(int bar[N])
And this gives you the size without an additional size parameter as you’d usually need in C (of course with the limitation that the parameter now has to be a compile-time sized array).

Re: C’s Biggest Mistake (2009)

#299

Post by pjmlp »

mytherin wrote: post #268
konjin wrote: post #156

Earlier quoted context omitted.

It's been 11 years, and C is running on more hardware than it ever has before, viz every android device. By what measure would C be losing ground?

The same is likely true of Fortran, since Fortran code is shipped around with several Python data science libraries and included in R. Does that mean Fortran is a thriving language, or does it just mean Fortran was used a long time ago to write some important libraries that are now hard to get rid of?

Except Fortran 2018 is quite modern, supports modules, generics, and even OOP, first class support on CUDA alongside C++, whereas C18 hardly changed since C89 besides some cosmetic stuff and it is as secure as when it got used to rewrite UNIX in the early 70s.

Re: C’s Biggest Mistake (2009)

#300

Post by jstimpfle »

Gibbon1 wrote: post #36
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…

All of this I agree with. In a better world 'arrays' would have added in the 1980's. The arguments about memory limitations is spurious since if you're writing good code you always pass a pointer and the length. Always no exceptions. Yeah and all the string functions should have been marked as depreciated with C89 and fully depreciated with C99.

There is a difference between passing a length as a function argument, and actually storing string lengths alongside the strings in memory.

It's not unheard of to have millions of tiny little (< 10 character) strings, and not storing lengths alongside them can shave off a sizeable portion of space requirements.

Post reply on HN