Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git's list of banned C functions

github.com

Post reply on HN
Print view View original

291–300 of 639 posts

Re: Git's list of banned C functions

#291

Post by user5994461 »

mxcrossb wrote: post #269
jchw wrote: post #45

Earlier quoted context omitted.

Unfortunately, much of the pain with C surrounds dealing with strings. It’s been a bit of a theme on Hacker News for the past few days, but it’s actually a pretty good spotlight on something I feel is not always appreciated - strings in C are actually hard, and even the most safe standard functions like strlcpy and strlcat are still only good if truncation is a safe option in a given circumstance (it isn’t always.) (…

What I don’t understand is why C programmers use the built in strings. It’s like rolling your own sorting algorithm every time you need it. Surely someone could write a better string library in C that hides the complexity. The real problem is that C programmers are apparently allergic to using other people’s code.

>>> Surely someone could write a better string library in C that hides the complexity.

In short, it's not possible to write a nice string library in C because C simply doesn't support objects, and by extension doesn't support libraries.

Strings are a perfect example of an "object" in what is later known as object oriented programming. C doesn't have objects, it's the last mainstream language that's simply not object oriented at all, and that prevents from making things like a nice string library.

If you're curious, the closest thing you will see in the C world is something like GTK, a massive C library including string and much more (it's more known as a GUI toolkit but there are many lower level building blocks). It's an absolute nightmare to use because everything is some abuse of void pointers and structs.

Re: Git's list of banned C functions

#292

Post by javbit »

GordonS wrote: post #234
ggregoire wrote: post #142

Earlier quoted context omitted.

> in JavaScript you have footguns like the with statement I've been coding in JS on a daily basis for more than 10 years and today I learned there is a `with` statement in JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Edit: well, seems like it's been deprecated/forbidden since ES5 (2009), so it makes sense I've never seen it.

And me around 20 years - also never even heard of the `with` statement! I think to qualify as a footgun, people actually need to be using it in the real world.

It should be called something like appendixgun then because you don't use it but it still has a chance of causing needless suffering and pain.

Re: Git's list of banned C functions

#293

Post by tedivm »

young_unixer wrote: post #279
paganel wrote: post #267

Earlier quoted context omitted.

This heavily filters for people who have had experience with programming in high-school or even before that, there's no way for a programming novice to pass that grueling routine. And then people rhetorically ask themselves why students coming from economically disadvantaged households are under-represented in this industry (one of the best paying industries in this time and age). Stuff like that has got to change.

I don't really get the correlation between household income and programming experience in high school. Their parents can't afford a laptop? They can't afford an Internet connection? The kids don't have a good place to learn in their house? They don't have time? Is programming affected more than other subjects like math, English/grammar, science, etc?

This may be less so now than it was 10 years ago, but I absolutely promise you that having a decent computer (not great, not a gaming pc, but just something that a kid can feel comfortable experimenting with) that is readily available (and not being shared with siblings) is absolutely a luxury.

Re: Git's list of banned C functions

#294

Post by Kaze404 »

sudomakeup wrote: post #162
Kaze404 wrote: post #106

Earlier quoted context omitted.

Why are these functions deprecated in favor of others but not removed? I know in Javascript this can happen so as to not break older websites, but in a compiled language this shouldn't be a problem right?

Why wouldn't it be an issue with a compiled language? Its nearly the exact same reasoning as "we're not going to break older websites"

In Javascript there's an expectation that Javascript written 15 years ago for Netscape will also work on Firefox 89. Is that also the case with C, wrt compiler versions? I've always assumed it wasn't.

Re: Git's list of banned C functions

#295

Post by IgorPartola »

ironmagma wrote: post #146
IgorPartola wrote: post #108

Earlier quoted context omitted.

What you said. Nobody is complacent. Anyone who thinks the Linux or OpenBSD (etc.) kernel developers take the lazy way out is talking about a thing they know little about. I do think better languages than C exist and maybe could even be used as a basis for new systems. But I have yet to see a mature OS that’s as secure and as performant as these. Closest might be the chips I’ve seen that have an embedded Java byte co…

I agree in principle but think these security-focused C developers are focusing on the trees for the forest. Every developer having the responsibility of cultivating their own pet list of banned functions is, frankly, NOT the way to achieve security. Those things need to be enforced at the widest level possible (OS, or language) to have the needed effect.

Two ways to look at it. If I told you that your computer or phone could run the same OS and all the same programs but at 1/10th of the speed so that certain classes of bugs could be eliminated, would you make that switch right here and now? I don’t mean theoretically I mean the device you are looking at right now. If not, would you do that in a year?

On the other hand, Moore’s law and all that. Computers will get faster over time so at some pint we might not care. And the opposite of my question is also true: if you could switch to a faster OS written in assembly, would you (assuming all functionality stays the same), knowing certain classes of bugs are more likely?

It seems to me that the cost of these kinds of bugs is amortized such that it is cheaper to use C than to switch. Expressed in those terms, we will only switch to a different language for all our systems stuff when the cost of the rewrite and the cost of the performance penalty are clearly and significantly less than the cost of the bugs we are likely to expedience.

Re: Git's list of banned C functions

#296

Post by MaxBarraclough »

kiwidrew wrote: post #265
munchbunny wrote: post #143

Earlier quoted context omitted.

The decision to make C strings null terminated with implied length instead of length + blob continues to trip us up, 30+ years later. There's a good reason the "safe" versions of those functions all take length parameters. But way back when this approach was chosen, I don't think the state of the art could fully predict this outcome. But also, "strings" and "time" are actually very complex concepts, and these functio…

I would argue that C's fundamental mistake (well, more like limitation due to hardware of the time) was allowing arrays to decay to pointers; arrays hold valuable type information (the length!) that is lost once converted to a pointer. C99 came so very very close with VLAs. You can declare a function like: int main(int argc, char *argv[argc]) { ... } But C99 requires the compiler to discard the type annotations and t…

See WalterBright's 2009 blog post, C’s Biggest Mistake, about exactly this.

https://digitalmars.com/articles/C-biggest-mistake.html

Re: Git's list of banned C functions

#297

Post by ggregoire »

GordonS wrote: post #241
viklove wrote: post #100

Earlier quoted context omitted.

It amuses me that HN hates JS so much, that even a topic about problems with C turns into a JS-bashing thread. Also, I just want to remind you that JS isn't just React. There are plenty of libraries written in C that introduce breaking changes over the course of 3 years. Nothing will stop people from finding ways to complain about JS though, I know. The hate-boner is very real.

I've been a long-time Javascript hater. Probably didn't help that I started out 20 years ago, and dealing with cross-browser support was a big issue. And of course, let's so no more about Internet Explorer shudder . And then NPM - a direct result of JavaScript's anaemic standard library. Anyway, things have changed a lot, and I recently worked on my first ever web app with native ES6 - no transpiling to ES5! It was..…

If static-typing is your thing, you should give a try to TypeScript. It's easily the biggest game changer that happened to the JS world in the recent years.

Re: Git's list of banned C functions

#298

Post by Biganon »

orwin wrote: post #184
InvOfSmallC wrote: post #103

Earlier quoted context omitted.

I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. The university decided to explain C to first year student without previous experience. My feedback was to do a precourse in Python to let them relax a bit with programming as a concept and then teach C in a second course.

In my school, we had two days to understand the basics of text editors, git (add, commit, rebase, reset, push) and basic bash functions (ls, cd, cp, mv, diff and patch, find, grep...) + pipes, then a day to understand how while, if/else and function calls work, then a day to understand how pointer work, then a day to understand how malloc(), free() and string works (we had to remake strlen, strcpy, and protect them).…

Piscine ?

Re: Git's list of banned C functions

#299

Post by _underfl0w_ »

young_unixer wrote: post #279
paganel wrote: post #267

Earlier quoted context omitted.

This heavily filters for people who have had experience with programming in high-school or even before that, there's no way for a programming novice to pass that grueling routine. And then people rhetorically ask themselves why students coming from economically disadvantaged households are under-represented in this industry (one of the best paying industries in this time and age). Stuff like that has got to change.

I don't really get the correlation between household income and programming experience in high school. Their parents can't afford a laptop? They can't afford an Internet connection? The kids don't have a good place to learn in their house? They don't have time? Is programming affected more than other subjects like math, English/grammar, science, etc?

> Their parents can't afford a laptop? They can't afford an Internet connection? The kids don't have a good place to learn in their house? They don't have time?

All of the above, and it's surprising this isn't obvious. It may be hard to notice or internalize if you've never seen it and only know privilege, but possession of all or even some of those things is not a guarantee for everyone. Believe it or not, there are some who don't come home to a computer, caring (or even existent!) parents, stable meals, or free time.

Re: Git's list of banned C functions

#300

Post by cletus »

InvOfSmallC wrote: post #103
jchw wrote: post #45

Earlier quoted context omitted.

Unfortunately, much of the pain with C surrounds dealing with strings. It’s been a bit of a theme on Hacker News for the past few days, but it’s actually a pretty good spotlight on something I feel is not always appreciated - strings in C are actually hard, and even the most safe standard functions like strlcpy and strlcat are still only good if truncation is a safe option in a given circumstance (it isn’t always.) (…

I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. The university decided to explain C to first year student without previous experience. My feedback was to do a precourse in Python to let them relax a bit with programming as a concept and then teach C in a second course.

If I had to choose a language to teach programmers to absolute beginners, I think I'd actually go with Go.

I understand the predilection for Python but there are some parts of Python that are just... odd.

Post reply on HN