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

311–320 of 382 posts

Re: C’s Biggest Mistake (2009)

#311

Post by dependenttypes »

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.)

void f(size_t n, int v[n]) is valid C.

Re: C’s Biggest Mistake (2009)

#313

Post by hanche »

YeGoblynQueenne wrote: post #310
AlphaSite wrote: post #252

Earlier quoted context omitted.

Linux is currently investigating using Rust in drivers (The main issue being lack of compiler support for the more isoteric architectures).

Thank you for the new knowledge that "eso" is pronounced similar to "iso" in some dialects of English, I didn't know that. However, the word "isoteric" is more correctly spelled (in non-phonetic spelling) as esoteric . The prefix "eso-" means "inside" in Greek, as in "esothermic", or "esophagus". The prefix "iso-" means "equal", as in "isomorphism", "isosceles", "isometric", etc.

Maybe dial back the sarcasm a notch or two?

Re: C’s Biggest Mistake (2009)

#314

Post by Koshkin »

dependenttypes wrote: post #311
Koshkin wrote: post #72

Earlier quoted context omitted.

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.)

void f(size_t n, int v[n]) is valid C.

Semantically though, the second argument is still just a naked pointer.

Re: C’s Biggest Mistake (2009)

#315

Post by johnisgood »

ComputerGuru wrote: post #212
johnisgood wrote: post #209

Earlier quoted context omitted.

Sure, it has not been standardized, it is not part of the standard library, so what? Did the world stop? I mean, practically speaking, who cares? Implement it, or find libraries that did. There are plenty. I posted this one because it exists for an OS; OpenBSD, since 1999 . Plus, AFAIK ohash is portable enough. It consists of 2 files, and you can compile it with -std=c89 . Only the bounded attribute is ignored. If yo…

I use stb myself, so I have no qualms with that. The point is rather that GP was discussing praise for C’s standard library, and even the most portable single-file include-only dependency remains just that: an external dependency that isn’t part of the C standard library (and no, posix isn’t C).

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 want it to have a hash table and all sorts of stuff like that, because there are lots and lots of ways to implement them, and they might not suit my needs. C is great, because you can build it from the ground up (if you want to) to make it specifically for your use case. It gives you the building blocks. I believe I have a comment regarding this somewhere, that I like C because it does not implement stuff for you that is in some ways "generalized", which is often a bad thing. This is my problem with "it should have hash tables at least". You cannot implement it in such a way that it suits everyone's needs.

Re: C’s Biggest Mistake (2009)

#316

Post by noisem4ker »

IshKebab wrote: post #256
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.

It is. Since 2012 C has dropped from about 4% of Github code to 3%. Meanwhile Rust has climbed from 0 to about 1%. That on its own doesn't prove that people are moving from C to Rust but it's not a risky guess. I did see some data on language transitions a while ago but can't find it now unfortunately (why is browser history search still so shit?). https://madnight.github.io/githut/#/pull_requests/2020/2

>(why is browser history search still so shit?)

Because Google wants people to search using the Google search engine, and see ads while they're at it. That would happen less often if Chrome were properly capable of searching the history.

Opera did full text history search a decade ago, but that browser doesn't exist anymore.

Also, history is expected not to be tied to the device in the cloud era. What more history data could you scalably sync other than URLs and page titles?

Re: C’s Biggest Mistake (2009)

#317

Post by rleigh »

nordsieck wrote: post #85
teej wrote: post #54

Earlier quoted context omitted.

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

> C code is being replaced by Rust fast. One of the key areas C is used that Rust cannot be used easily is in limited embedded devices. That looks like it'll be the case for at least 10 years and probably much longer than that.

Many, if not most, small MCUs can also run C++ these days as just as well as C. If you want to write simpler and more robust applications, it's easily achievable.

Re: C’s Biggest Mistake (2009)

#318

Post by rleigh »

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…

Look how many C library functions implicitly call strlen() internally.

Also, look at functions like sscanf(). It can be orders of magnitude slower than fscanf() because every invocation calls strlen while fscanf incrementally reads from the current file pointer. I don't know why sscanf doesn't also work incrementally but the implementations I've tested don't do that.

The main point here being: if strings had a size_t size plus data, that would change an O(n) scan to an O(1) length lookup, and that would have huge performance gains throughout the C library, not to mention your own code as well.

Re: C’s Biggest Mistake (2009)

#319

Post by pjmlp »

alternatetwo wrote: post #204
Reelin wrote: post #117

Earlier quoted context omitted.

This has always bugged me as well. I've generally solved this by wrapping things in a struct. Type checking will use the (incompatible) wrappers and a modern compiler should optimize them away. To avoid strict aliasing violations when converting between equivalent wrapped types you can use a union and employ a function to hide the verbosity. I have no idea if this is the "right" way to do things, but it seems to work…

That's what Microsoft did from some version on in their build tools, all the HANDLE's etc used to just be typedef void , now they're a dummy struct each (HANDLE__ ). Seems to be a good solution.

That was already opt-in back in the Windows 3.1 days, but few bothered to use it as such.

Back when I was doing pure Windows C for a while, this helped quite a bit,

Basically you had to #include and define the STRICT macro.

There were also several utilities that made it much easier to deal with events, dialogs and callbacks.

https://docs.microsoft.com/en-us/windows/win32/api/windowsx/

https://jeffpar.github.io/kbarchive/kb/083/Q83456/

I got to learn it via the "Programmer's introduction to Windows 3.1" book,

https://archive.org/details/programmersintro00myer

Re: C’s Biggest Mistake (2009)

#320

Post by extempore »

hanche wrote: post #313
YeGoblynQueenne wrote: post #310

Earlier quoted context omitted.

Thank you for the new knowledge that "eso" is pronounced similar to "iso" in some dialects of English, I didn't know that. However, the word "isoteric" is more correctly spelled (in non-phonetic spelling) as esoteric . The prefix "eso-" means "inside" in Greek, as in "esothermic", or "esophagus". The prefix "iso-" means "equal", as in "isomorphism", "isosceles", "isometric", etc.

Maybe dial back the sarcasm a notch or two?

He wasn’t being sarcastic.
Post reply on HN