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

351–360 of 382 posts

Re: C’s Biggest Mistake (2009)

#351

Post by WalterBright »

jstimpfle wrote: post #295
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 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…

If you ask printf to right justify a string, it'll do a strlen.

Re: C’s Biggest Mistake (2009)

#352

Post by WalterBright »

jstimpfle wrote: post #300
Gibbon1 wrote: post #36

Earlier quoted context omitted.

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.

Anytime a program has a special case like that, it makes sense to craft an optimal data structure for it.

Also, consider that the terminating 0 byte isn't just one byte. There's also the alignment of what malloc returns, which may be 4 or 8 or even 16 bytes.

Re: C’s Biggest Mistake (2009)

#353

Post by johnisgood »

baby wrote: post #341
johnisgood wrote: post #315

Earlier quoted context omitted.

Does it make much of a difference though? Take the hyped Rust for example. Most useful stuff is in crates, i.e. an external dependency. No one seems to have a problem with that. Personally I do not mind using libraries typically installed by the Linux distribution's package manager anyways. If the question is whether or not I think the C standard library could be improved, then yes, I would say it could, but I do not…

Rust not having a good standard library is a huge problem. This increases the risk of a rust codebase due to the high number of third party dependencies.

I only said that "I do not mind using libraries typically installed by the Linux distribution's package manager", which was in respect to C.

As far as Rust goes, yes, I do not like that crates are full of one-liners, and so forth. It shares the same problems that npm has. I ran cargo build on many Rust projects before. No way.

Re: C’s Biggest Mistake (2009)

#354

Post by konjin »

noisy_boy wrote: post #199
konjin wrote: post #153

Earlier quoted context omitted.

It isn't. You can tell how much a language is used by the inverse of the number of blogposts about it. People who have jobs don't have the time to write about how they would solve problems using that language, because they already are and have better things to do in their free time.

Number of blogposts about Python is a counter-argument.

The number of people employed as python programmers is vastly smaller than the number of people who can write hello world in python, which is what the majority of blog-spam is about.

Re: C’s Biggest Mistake (2009)

#356

Post by hvdijk »

jstimpfle wrote: post #308
hvdijk wrote: post #305

Earlier quoted context omitted.

I didn't mean compound literals, I do not really see how they change things here, I meant that there are a few cases where arrays don't decay to pointers, and supporting those requires compilers to make arrays a part of the type system. Example: given "int a[3];", how else would you compute (&a+1) ?

To me, the question is what is actually "the type system" and what is "the allocation system" or whatever else aspect of implementing a compiler. So determining the type of "&a" is not an issue, it's just one case in determining the type of a C expression (look up the object "a", is it an array? The type of the expression is a pointer to the array element type). This is not a special case, at least not more special t…

Are you aware that given int a[3];, (&a+1) and (a+3) denote the same address? If you are, how can that possibly work if as you suggest, &a and a are indistinguishable to the compiler, that they are both seen as a pointer to int?

Re: C’s Biggest Mistake (2009)

#357

Post by msla »

WalterBright wrote: post #240
msla wrote: post #216

Earlier quoted context omitted.

> Google the name of the person before responding to them Is it a rule at HN that you can't take someone else's name? Otherwise, there's no guarantee that you're talking to the "Real" Walter Bright... ... or that you're talking to that Walter Bright, come to think of it.

There can be only one.

But The One doesn't get the username.

Re: C’s Biggest Mistake (2009)

#358

Post by sam_lynx »

Stratoscope wrote: post #257
sam_lynx wrote: post #237

Earlier quoted context omitted.

I’m new here, so this seems like a valid criticism to me — but judging by the number of downvotes, it may not be. Can someone explain why this comment is incorrect?

Perhaps because so many of know Walter from his work and his history here on HN? Sometimes you have to just trust that someone is who we all say they are.

Cool, thanks for the explanation.

Re: C’s Biggest Mistake (2009)

#359

Post by sam_lynx »

genocidicbunny wrote: post #248
sam_lynx wrote: post #234

Earlier quoted context omitted.

Well, he dismissed Bright’s argument as a random pet peeve from people who haven’t written a line of code in C before, so yes, I do think he said it explicitly.

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. This is one of HN's comment guidelines. If you're not sure that someone is who you think they are, you can just ask, e.g.: "Hey, are you Walter Bright who did X and Y?"

? I’m confused how your comment relates to mine. Did you post on the wrong thread?

Re: C’s Biggest Mistake (2009)

#360

Post by jstimpfle »

WalterBright wrote: post #352
jstimpfle wrote: post #300

Earlier quoted context omitted.

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.

Anytime a program has a special case like that, it makes sense to craft an optimal data structure for it. Also, consider that the terminating 0 byte isn't just one byte. There's also the alignment of what malloc returns, which may be 4 or 8 or even 16 bytes.

malloc also has internal bookkeeping overhead, typically 16-32 bytes per allocation.

Which is why one should never allocate a single (short) string from a generic allocator. Instead, one allocates a big chunk upfront (e.g. 4K bytes or more), and breaks from that, using a simple index that points to the first unused bytes.

In this way, the overhead of allocating a string is truly only the terminating zero byte - no alignment constraints. This scheme is easy to implement as long as strings don't need to be freed individually.

Post reply on HN