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

241–250 of 639 posts

Re: Git's list of banned C functions

#241

Post by GordonS »

viklove wrote: post #100
IgorPartola wrote: post #83

Earlier quoted context omitted.

This is a lot like how in JavaScript you have footguns like the with statement or in Python 2 where you have Unicode issues, etc. I am sure we could definitely a new C standard that excludes these functions as obsolete, but the linked header file is a pretty sensible interim solution. C is an old language and it’s kind of amazing that code written 30 years ago can still by and large be compiled by a modern compiler.…

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... not nearly as bad as it used to be! Modules are a thing, and the language has evolved with things like async/await, evolved for the better, I think. The standard library is still horribly anaemic though - the number of "helper" functions needed is ridiculous.

But still, I would no longer classify myself as a hater. Progress at last :)

Re: Git's list of banned C functions

#242

Post by syncsynchalt »

at_a_remove wrote: post #213

I have only ever dabbled in C, just to look at other people's code and occasionally when I really needed speed, so I am at what I would call a "Pretty Pathetic" level, able to recognize that I am looking at C. However, I look at old books on C, and then I look at this list, and I wonder if it would not have been helpful to, after mentioning that a function was banned, suggest what the replacement is, even as a commen…

You're not wrong. But a seasoned C developer looks at this list and nods along. (I'm a little out of practice, but I have war stories for most of these).

It's likely that the authors of this list didn't think the comments would be worthwhile for the audience (git developers).

Re: Git's list of banned C functions

#243

Post by Blikkentrekker »

munchbunny wrote: post #180
Blikkentrekker wrote: post #161

Earlier quoted context omitted.

> But also, "strings" and "time" are actually very complex concepts, and these functions operate on often outdated assumptions about those underlying abstractions. Even in safer languages such as Rust , there are often quæstions as to why certain string operations are either impossible, or need to be quite complicated for a rather simple operation and are then met with responses such as “*Did you know that the length…

> locale settings of environment variables Also known as "why does my code that parses floats fail in Turkey?" Also also known as the discrepancy between a string's length-as-in-bytes, its length-as-in-code-points, and its length-as-in-how-humans-count-glyphs. Strings are hard. Edit to respond to your addendum: > P.s.: In fact, I would argue that strings are not necessarily all that complicated, but simply that many…

> Also known as "why does my code that parses floats fail in Turkey?"

I am quite certain that I have produced code that lowercases or uppercases and then checks for “i” in them, that I now realize would fail under Turkish locale settings as under that “i” does not uppercase to “I”, as one might expect.

Re: Git's list of banned C functions

#244

Post by syncsynchalt »

attractivechaos wrote: post #16

I wonder how they copy strings with strcpy and strncpy both banned. strlcpy? But it is not conforming to major standards. Or just memcpy with extra code?

strncpy is a dangerous function because it doesn't nul terminate on overflow. The danger is that it's named misleadingly (str* functions otherwise always work in nul-terminated strings).

(strcpy is just banned because there's no bounds check, and they want to force use of strlcpy instead).

Re: Git's list of banned C functions

#245

Post by pix64 »

throwaway09223 wrote: post #37
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.

Many of C's problems relate to string handling. These are all legacy functions which have been replaced with safe alternatives many decades ago. strcpy() was replaced with a safer strncpy() and in turn has been replaced with strlcpy(). The list is a ban of the less safe versions, where more modern alternatives exist.

strlcpy() isn't standard. You have to provide your own implementation if you want your code to be portable.

Re: Git's list of banned C functions

#246

Post by attractivechaos »

alcover wrote: post #192
attractivechaos wrote: post #66

Earlier quoted context omitted.

This gets me interested. Link [1] below shows their implementation of strlcpy(). This is a questionable implementation. With strncpy, the source string "src" may not be NULL terminated IIRC. The git implementation requires "src" to be NULL terminated. If not, an invalid read. EDIT: according to the strlcpy manpage [2], "src" is required to be NULL terminated, so strlcpy imposes more restrictions and is not a proper r…

Agreed. It's O(n) inefficient. I guess looping though chars up to `size` would perform better on average. I see this `strlcpy` recommanded everywhere.

A few days ago people here were discussing the quadratic sscanf() behavior. strlcpy() has the same problem.

Re: Git's list of banned C functions

#247

Post by michaf »

selfhoster11 wrote: post #199
JoeAltmaier wrote: post #175

Earlier quoted context omitted.

Hey, languages used length,blob even when C was invented. HP Access BASIC used that kind. It was a limitation, because they chose a byte length (to save space). So strings up to 255 characters only. It was decades before folks were comfortable with 32-bit length fields. And that still limited you to 4GB strings. In the bad old days, memory usage was king.

The funny thing is that you can just use the topmost bit of the length to indicate that the string length is >127, and chain as many length bytes as you want before you begin the string proper (to save space). It would be still a better encoding than a null at the end.

This way you would trade in a null-byte-terminated variable length string for essentially a null-bit-terminated variable length number (plus the remaining string). I am not convinced that this actually would be much safer.

Re: Git's list of banned C functions

#248

Post by lultimouomo »

jdlshore wrote: post #212
munchbunny wrote: post #193

Earlier quoted context omitted.

The prefix approach turns the neat "strings are just character arrays are just pointers" pattern into something a lot more clunky, because now you've got this really basic data type that is actually a struct and now you have to have an opinion on how wide the length value is and short strings get a lot of memory overhead in just lengths, and so on. In hindsight, I think the complexity is worth the safety, but I could…

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

Re: Git's list of banned C functions

#249

Post by unbalancedevh »

frob wrote: post #138
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.

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.

Re: Git's list of banned C functions

#250

Post by chris_wot »

skeletal88 wrote: post #238
adrianmonk wrote: post #97

Earlier quoted context omitted.

> Why not check the git history? Because that is effort every person who uses the file has to do over and over again, whereas maintaining the file is effort that has to be done once by one person.

Someone here commented to use git blame to find the commit that banned the functions and read the commits. These people making the suggestions.. must hate other people and their time. Also, what if someone.. for example runs a code formatter on the file, making git blame useless? Is it really so difficult to make a manual or explain properly in the comments about what replacements to use?

Try:

  git blame -w -M
This will ignore whitespace and detect moved or copied lines.
Post reply on HN