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

311–320 of 639 posts

Re: Git's list of banned C functions

#311

Post by gpanders »

unbalancedevh wrote: post #249
frob wrote: post #138

Earlier quoted context omitted.

As someone who learned C as their first language, strings in every single language after that have felt like cheating. "What? You mean I can type an arbitrary string and it works? I don't need to worry about terminators or the amount of memory I've allocated? You can concatenate two strings with +?!? What is this magic?"

It always makes me wonder if there's some hidden overhead that I'm absorbing. When I program in C I feel like I know a lot better what the generated instructions will be. Using higher-level languages for embedded programming where resources are tight makes me uncomfortable.

Basically every (non-C) string implementation in existence has to do dynamic memory allocation under the hood, which is hidden from the programmer. That’s the overhead.

Re: Git's list of banned C functions

#312

Post by hguant »

cletus wrote: post #300
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.

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.

Python is great fun, and you can be really productive with it, but for people first coming into programming, a language with an explicit and strict type system is invaluable.

I used to think that everyone should be taught python first, because it lets you focus on the meat of computer science - algorithms, data manipulation, actually _doing_ something - but after helping my girlfriend out with some comp sci 101-104 projects, I really think Go, Java, or Rust should be everyone's first language. It's hard for someone new to the field to understand the nuances that come with python's corner cutting. You can work yourself into some weird corners because of how permissive the language is, where in a (strongly) typed language, the complier just says no.

Re: Git's list of banned C functions

#313

Post by xxpor »

closeparen wrote: post #181
lmilcin wrote: post #67

To respond to some of the comments. It is not that there is anything intrinsically wrong with these functions. You can technically use all of them and I have been using all of them, safely, for decades. The issue is they are huge traps to the point that in a larger piece of software one can say "well, it's just not worth it". You can go much, much, much further than that. In couple embedded projects I worked some of…

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

It's an embedded system, it's very likely there's no OS in the first place.

Re: Git's list of banned C functions

#314

Post by kiwidrew »

MaxBarraclough wrote: post #296
kiwidrew wrote: post #265

Earlier quoted context omitted.

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

Ah, indeed! Thanks for the link.

I think many of the "safe C" variants get tripped up by starting with fat pointers (length + pointer as an atomic value) and then have trouble (rightly so!) when trying to squeeze them through the C standard ABI; it's a square peg in round hole sort of situation.

The key observation from WalterBright's post is that the C standard ABI already has a way to pass fat pointers, using a pair of arguments (size_t and char *) in an ad-hoc manner.

It's the not-useful-but-legal C99 VLA declaration in the function prototype that could, if one is willing to violate the C99 spec, allow a compiler to automatically derive a fat pointer inside the body of a function in a manner that is backwards-compatible with the C standard ABI.

Re: Git's list of banned C functions

#315

Post by quickthrowman »

gravypod wrote: post #237
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.

Sorry to bug you since this is unrelated. I'm a huge fan of teaching others and I was wondering how you got to be an external lecturer at a college? I'd love to teach classes related to software engineering and data structures. Would you mind emailing me (in my profile) about this?

I’d imagine you look for job openings for “adjunct professor” or “instructor” at universities. You can look forward to part-time employment with no benefits and no chance for tenure (this isn’t a dig at adjunct faculty, it’s unfair how it works in the US). Depending on the field of study and school, you need anywhere from bachelors to a PhD to qualify.

Re: Git's list of banned C functions

#316

Post by DaiPlusPlus »

cestith wrote: post #270
DaiPlusPlus wrote: post #202

Earlier quoted context omitted.

At a certain point we have to say that it’s wrong for someone to expect C89 should still be the LCD. And yes: it should all still compile, but none of that prohibits the compiler from issuing flashing red/yellow warning messages to your terminal for using footgun functions, preferably with uncomfortable audible notifications too. All of this is silly though, because even in a strict C89 environment you can still have…

I think for new code in environments that support newer standards C89 shouldn't be used. For the increasingly rare places new C is being written where C89 is the latest tooling available and the code handles strings, a safer string library is nearly a must. I strongly recommend a safer string library no matter which standard, but I'm nobody. When updating existing code C89 (maybe K&R) might be what's used so minor co…

> I think for new code in environments that support newer standards C89 shouldn't be used

Why stop there? Don't use C. Use Rust!

Re: Git's list of banned C functions

#317

Post by monocasa »

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.

I've actually had more success teaching assembly as a first language than C. There's less magic, and you borderline have to start with the indirection of pointers in a way that people seem to grok a lot easier than the last month of the semester of learning C.

Re: Git's list of banned C functions

#318

Post by cb321 »

unnouinceput wrote: post #281
lordgroff wrote: post #216

Earlier quoted context omitted.

Oh Pascal, why couldn't we have had you instead.

You can, it's called Delphi.

Or Nim [1]. :-) It's hard to describe succinctly, but "Pascal meets Ada meets Python meets Lisp-like syntax macros" starts to convey it. Forget operator overloading trying to square peg-round hole whatever the operator set is - Nim has user-defined operators. And a dozen other nice things.

https://nim-lang.org

Re: Git's list of banned C functions

#319

Post by joshuacc »

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?

Yes! There are millions of kids in the US whose parents can't afford a cheap $300 laptop. The federal government pays for school lunches because there are so many kids who otherwise wouldn't even be getting decent food otherwise.

> They can't afford an Internet connection?

See above. Also, there are many places in the US where getting broadband service is very difficult. Including places just an hour outside of Washington, DC. My parents were only able to get conventional broadband service a few years ago. Prior to that they paid exorbitant fees for satellite internet service with a 500mb per month cap.

> The kids don't have a good place to learn in their house?

Imagine being a kid with 3 siblings and your parent(s) living in a studio apartment. Or a kid that doesn't have a stable "home" at all.

> They don't have time?

That can be an issue too, depending on age. A teenager may be working outside of school hours to help take care of the family's financial needs.

Re: Git's list of banned C functions

#320

Post by IgorPartola »

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.

I have seen it in the wild. I first learned of it from Douglas Crockford’s JavaScript the good parts. He also had some things to say about the new keyword and prototype inheritance and how we should stop using them. Ironically while he was dismissed on that suggestion then, VueJS has pretty much implemented exactly what he has in mind in their V3.
Post reply on HN