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

271–280 of 639 posts

Re: Git's list of banned C functions

#271

Post by moonchild »

masklinn wrote: post #69
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.) (…

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

Microsoft's implementations are distinct and incompatible (and they haven't changed to be compatible with the standard versions because of backwards compatibility).

Re: Git's list of banned C functions

#273

Post by moonchild »

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…

It's because to get that to actually work you need dependent types. Which—it's not gonna happen.

Re: Git's list of banned C functions

#274

Post by rightbyte »

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.

> How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program?

You could maybe call filescope buffers with an size counter a dynamic memory allocation. I.e. for storing RS232 or CAN messages. Since they shrink and grow.

The important thing is that you want to know that flooding one buffer wont flood another, which malloc could result in if it was used for unrelated buffers.

Re: Git's list of banned C functions

#276

Post by tester756 »

SavantIdiot wrote: post #57
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.

If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew…

Just because I want to know people opinion's (+they may be more than happy to shit on C#:)

C#

But please, nothing about using unsafe.

Re: Git's list of banned C functions

#277

Post by MaxBarraclough »

lvs wrote: post #257
kazinator wrote: post #198

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. But if you keep up the good work you will one day go from extern void *lecturer; to static const lecturer;

More commonly volatile unsigned short lecturer;

In C++ we'd have to decide if lecturer needs to support move semantics.

Re: Git's list of banned C functions

#278

Post by unnouinceput »

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…

"Can you imagine trying to make a run-time for a high level language in Pascal"

You mean like the strings in Delphi? Yeah, I can since I use them daily. Strings in Delphi nowadays are actually more like classes in java than Old Pascal strings. Then depending on your intend either get them to be arrays or old strings after linker goes over your code. Best of both worlds, and on top of it, if you really want, you can definitely shoot yourself in your leg with unsafe operations. So in the end is best of both worlds and worse of 3rd world. Though the 3rd one you really need to go out of your way to have it as bad as C strings are.

Re: Git's list of banned C functions

#279

Post by young_unixer »

paganel wrote: post #267
orwin wrote: post #184

Earlier quoted context omitted.

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

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?

Re: Git's list of banned C functions

#280

Post by UncleMeat »

ggregoire wrote: post #142
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.…

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

An old grad school connection of mine wrote a formal semantics for ES5 and couldn't explain what "with" did in words.
Post reply on HN