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

371–380 of 639 posts

Re: Git's list of banned C functions

#371

Post by nrdvana »

kazinator wrote: post #220
retrac wrote: post #166

Earlier quoted context omitted.

For reasons that were never clearly articulated, the prefix approach was considered odd, backwards, and to have numerous downsides, at least where I learned C. In hindsight, I can only cringe at that attitude. Strings as added in later Pascal, about 40 years ago now, were memory safe in a way that C strings still are not.

Pascal strings are not inherently memory safe: cat_pascal_strings(pascalstr *uninited_memory, pascalstr *left, pascalstr *right); how big is uninited_memory? Can left and right fit into it? You need to design language constructs around Pascal srings to make them actually safe. Such as, oh, make it impossible to have an uninitialized such object. The object has o know both its allocation size and the actual size of th…

In the Pascal that I remember, strings were always 256 bytes and the first byte tracked the length, meaning they were always safe, though might get truncated. The LongString just did allocations whenever it needed, and was also safe, as long as you weren’t rolling your own pointer math.

Re: Git's list of banned C functions

#372

Post by SAI_Peregrinus »

DaiPlusPlus wrote: post #316
cestith wrote: post #270

Earlier quoted context omitted.

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!

Rust doesn't (yet) support all the targets C does. Mostly weird embedded stuff that needs it, and gccrs might solve that problem, but it's not always possible.

When it is possible, I certainly agree that Rust is nicer.

Re: Git's list of banned C functions

#373

Post by kevin_thibedeau »

retrac wrote: post #166
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…

For reasons that were never clearly articulated, the prefix approach was considered odd, backwards, and to have numerous downsides, at least where I learned C. In hindsight, I can only cringe at that attitude. Strings as added in later Pascal, about 40 years ago now, were memory safe in a way that C strings still are not.

On platforms with limited register sets, keeping length around burns a register that could be used for something else. From the mindset of assembler programmers wanting a high level language that suits them, a sentinel that doesn't consume extra machine resources was preferable. Not to mention all the precious RAM those multi-byte lengths squander.

Re: Git's list of banned C functions

#374

Post by [deleted] »

nrdvana wrote: post #371
kazinator wrote: post #220

Earlier quoted context omitted.

Pascal strings are not inherently memory safe: cat_pascal_strings(pascalstr *uninited_memory, pascalstr *left, pascalstr *right); how big is uninited_memory? Can left and right fit into it? You need to design language constructs around Pascal srings to make them actually safe. Such as, oh, make it impossible to have an uninitialized such object. The object has o know both its allocation size and the actual size of th…

In the Pascal that I remember, strings were always 256 bytes and the first byte tracked the length, meaning they were always safe, though might get truncated. The LongString just did allocations whenever it needed, and was also safe, as long as you weren’t rolling your own pointer math.

[deleted]

Re: Git's list of banned C functions

#375

Post by astrange »

jchw wrote: post #115
masklinn wrote: post #69

Earlier quoted context omitted.

> Technically C11 has strcpy_s and strcat_s "Theoretically" is the word you're looking for: they're part of the optional Annex K so technically you can't rely on them being available in a portable program. And they're basically not implemented by anyone but microsoft (which created them and lobbied for their inclusion).

I didn’t know that it was Microsoft that lobbied for them; that perplexes me since I thought Microsoft’s version of them were a bit different (for example, I think C11’s explicitly fail on overlapping inputs where Microsoft specifies undefined behavior) and because Microsoft didn’t bother supporting C99 for the longest time. (Probably still don’t, since VLA was not optional in C99, IIRC. I think Microsoft was right t…

VLA syntax can be useful because you can cast other pointers to them - for instance you can cast int* to int[w][h] and then access it as [y][x] instead of [y*w+x].

As a bonus this crashes icc if you do it.

Re: Git's list of banned C functions

#376

Post by konjin »

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.

You're just moving the complexity from strings into unsigned integers. Your strings are limited by the size of whatever you put in the head of the string.

Sure 16 exabytes sounds like a lot today, but so did 4 billion ip addresses. Differently bad is not better.

Re: Git's list of banned C functions

#377

Post by astrange »

javbit wrote: post #292
GordonS wrote: post #234

Earlier quoted context omitted.

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.

The appendix is a reservoir of gut bacteria in case you lose yours in an infection or by taking too many antibiotics.

Re: Git's list of banned C functions

#378

Post by userbinator »

At least they didn't ban memcpy()...

Much like with all other forms of effective censorship, I see this as a quick short-term "fix" with hidden long-term costs[1]. IMHO this sort of anti-thinking just leads to even worse, more dogmatic and cargo-cult, programmers who know less and less about the basics and then go on to make even more subtle errors.

Somehow the collective software industry has managed to propagate the notion that people are incapable of doing even basic arithmetic. Yet they think people are capable of creating complex systems with even more subtle behaviour? The justification would normally be because it's not directly affecting security. WTF. It's beyond stupid.

The only C function I think should be truly banned is gets(), because it is actually impossible to calculate what size of buffer it needs. That is not true of any of the others on this list.

[1] By short and long, I mean decades vs centuries.

Re: Git's list of banned C functions

#379

Post by xxpor »

lmilcin wrote: post #369
xxpor wrote: post #313

Earlier quoted context omitted.

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

Actually it is irrelevant whether you use an operating system or not. One project I worked with these rules was on Verix OS. The rules are more intended on reducing application complexity and unpredictability which is typically helping reliability regardless of the setting.

It was mostly on if the OS would actually allocate physical memory, or if it'd do a linux style overcommit. Without an OS, the latter is very unlikely.
Post reply on HN