Git's list of banned C functions • Hacker News Board

Re: Git's list of banned C functions

#401

Post by illirik » Fri, Mar 05, 2021, 2:03 AM UTC

astrange wrote: post #368

Sohcahtoa82 wrote: post #338

Earlier quoted context omitted.

> I don't really get the correlation between household income and programming experience in high school. > Their parents can't afford a laptop? Holy crap, the amount of privilege shown off in just two sentences is absolutely astounding. This may come as a shock to you, but a very significant number of people don't have a couple hundred dollars to buy a low-end used laptop. 40% of Americans would struggle to come up w…

> 40% of Americans would struggle to come up with $400 for an emergency expense [0], let alone save $400 for a laptop. It actually doesn't say that, it says they don't have $400 in cash equivalents but may be able to produce it by selling "assets". So a person who keeps all their savings in CDs or investments also counts, although only for expenses you can't put on credit cards.

The working poor simply don't have the safety net of good credit or wealthy families that the vast majority of HN commenters do. If you're living paycheck to paycheck and get a $400 surprise expense, you don't have $400 just sitting in some money market account, or two shares of SPY they can just sell, because the poverty wages being paid to millions of working people leave zero margin to build any sort of financial security, leading to a kind of precariousness that is unimaginable to the educated professional with a comfortable upbringing. "Assets" means things like a wedding ring, some power tools, a computer, or maybe even a 1995 Dodge Neon; if you go to a pawn shop, you can see the sorts of things people pawn (or sell) when they desperately need $400 for an emergency expense.

They often take payday loans, mortgaging their next minimum-wage paycheck; since the next paycheck minus payment no longer covers their regular living expenses, they take another predatory loan or pawn another heirloom. 80% of people who take a payday loan have to renew it because they can't repay it. I have a deep personal dislike for Dave Ramsey, but he does a good job of explaining how even minor emergency expenses can lead to a cycle of debt and further despair. (https://www.daveramsey.com/blog/get-out-payday-loan-trap)

There is so much more instability and precarity in this country than most PMC people can imagine.

Re: Git's list of banned C functions

#402

Post by wahern » Fri, Mar 05, 2021, 2:06 AM UTC

throwaway09223 wrote: post #240

_kst_ wrote: post #68

Earlier quoted context omitted.

strncpy() is not a "safer" strcpy(). It can avoid some errors involving writing past the end of the target array ( if you tell it the correct length for that array), but it's not a true string function, and it can leave the target unterminated and therefore not a valid string. http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

In the interest of satisfying pedantry I think we can agree that strncpy() is intended to be a safer strcpy() for a subset of uses. As you say, it does in fact obviate some errors. A value judgement as to which behaviors are more or less safe may be subjective, but the intent is not.

strncpy was never intended to be a safer strcpy. It was created for a very specialized use case in the Unix kernel--copying a string-ish identifier to a fixed-size char field that only uses NUL termination if the identifier is shorter than the field size. Because of how the C language and the Unix kernel coevolved, it became part of the standard C library by default. I've seen it used for it's original semantics in only a handful of places, but in general it's almost always misused.

To be clear, strncpy does not guarantee NUL termination. It takes a C string as the source argument, but it doesn't write out a C string; it writes out a very esoteric data structure that is unfortunately easily confused with a C string.

By contrast, strlcpy was intended to be a safer string copy routine: https://www.usenix.org/legacy/event/usenix99/full_papers/mil... In particular, it was designed to be what people seem think strncpy is. Its return value semantics are controversial, though mostly only among the glibc crowd as every other Unix libc, including musl and Solaris, now provide it. But the semantics were designed based on experience in fixing old C code, and observations about how developers tend to write C code, not based on prescriptive theories about how people should manipulate C strings in C code.

Re: Git's list of banned C functions

#403

Post by nwallin » Fri, Mar 05, 2021, 2:09 AM UTC

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?

74% of American families own a computer. The other 26% do not. Incomes are also highly clustered- chances are any given cohort of high school students either has 90% or more or 10% or less kids with computers, without a lot in between. Relatively poor districts may have a very general computer literacy class (typing, word processing, spreadsheets) but won't have a programming class, because the logistics of getting them adequate time at a computer to complete the work is impossible.

https://www.statista.com/statistics/756054/united-states-adu...

Re: Git's list of banned C functions

#404

Post by azernik » Fri, Mar 05, 2021, 2:17 AM UTC

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.

There are lots of more conventional footguns in JS, though - everything about the Date object/class, for example.

Re: Git's list of banned C functions

#405

Post by ByteJockey » Fri, Mar 05, 2021, 2:18 AM UTC

lultimouomo wrote: post #248

jdlshore wrote: post #212

Earlier quoted context omitted.

It's a classic case of moving the complexity from one part of the system to another. "Strings are just character arrays" seems simple and elegant, but in reality is a giant mess, because strings are not just character arrays, any more than dates are just an offset from an epoch. Human concepts are inherently messy. "Elegant" solutions just shove the mess down the road.

On the contrary, I think "Strings are just character arrays are just pointers" is the solution, not the problem. As with non-character arrays, you must always pair the pointer with a length. (I don't like the idea of prefixing the length because it prevents su stringing). The problem is the null termination, which is not general to arrays (though it is sometimes used with arrays of pointers).

You sometimes see sentinel values used with varargs (only if they're all the same type), which is basically just an array with more boilerplate.

That being said. Length as a first parameter and the rest of the arguments being the variadic bit is also quite normal.

Re: Git's list of banned C functions

#406

Post by Kaze404 » Fri, Mar 05, 2021, 2:19 AM UTC

int_19h wrote: post #357

Kaze404 wrote: post #294

Earlier quoted context omitted.

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.

It's very much the case, so long as you stick to standard C (the full limitations of which very few people are actually aware of). Runtime backwards compatibility is similarly extensive on platforms that care about it. You can still take a DOS app written in ANSI C89 the year that standard was released, and run it on (32-bit) Windows 10, and it'll work exactly the same. In fact, you can do this with apps all the way…

Wow, that's super interesting. Thank you :)

Re: Git's list of banned C functions

#407

Post by jxy » Fri, Mar 05, 2021, 2:24 AM UTC

paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

That's an unfortunate result of backward compatibility. If it were Python, it would just become v2 and tell people to suck it up.

Re: Git's list of banned C functions

#408

Post by dahfizz » Fri, Mar 05, 2021, 2:25 AM UTC

syncsynchalt wrote: post #236

dahfizz wrote: post #23

Earlier quoted context omitted.

This was my reaction as well. Banning strncpy just encourages haphazard manual copying.

strncpy doesn't do what you think it does (it is not analogous to strncat). strncpy does not terminate strings on overflow. In C terms, it is not actually a string function and shouldn't be named with `str`. snprintf or nul-plus-strncat do what you want, but snprintf has portability problems on overflow. Most projects I've been on rely on strlcpy (with a polyfill implementation where not available).

strnlen may be surprising the first time you see it not null terminate, sure. But if you use the n version of all the string functions (which you should anyway) then it's safe.

Re: Git's list of banned C functions

#409

Post by ChrisRR » Fri, Mar 05, 2021, 2:29 AM UTC

paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

Strings are half the reason I never recommend someone learns C as their first language. Python is much easier, and then you can pick up C afterwards when you've got a better baseline knowledge

I've seen the same question posted way too often by beginners to C. "I've created a char*. Why am I getting when I try to write to it?"

Re: Git's list of banned C functions

#410

Post by kelnos » Fri, Mar 05, 2021, 2:32 AM UTC

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.

Because most projects involve interfacing with other third-party libraries that will undoubtedly not know about this other third-party library that implements a nice string.