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

181–190 of 639 posts

Re: Git's list of banned C functions

#181

Post by closeparen »

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.

Re: Git's list of banned C functions

#182

Post by badsectoracula »

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…

> when will we see the Unreal Engine written in...

Why would a huge C++ (not C, btw) codebase with roots going back to the 90s be rewritten in any other language?

And in fact how is the language Unreal Engine written in relevant to C having footguns?

Re: Git's list of banned C functions

#183

Post by macjohnmcc »

jchw wrote: post #45
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.

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

strcpy is a coding challenge where I work for interviews. I typically ask them to write it as the standard version and ask them why they might not want to use it to see if they are aware of the risks. After that I ask them to modify the code to be buffer safe. And for those claiming C++ knowledge ask them to make it work for wchar_t as well to see if they can write a template. Some people really struggle with this.

Re: Git's list of banned C functions

#184

Post by orwin »

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.

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). Two days, over the weekend, to do a small project to validate this.

Then on the monday, it was makefiles if i remember correctly, then open(), read(), close() and write(). Then linking (and new libc functions, like strcat) . A day to consolidate everything, including bash and git (a new small project every hour for 24 hours, you could of course wait until the end of the day to execute each of them). And then some recursivity and the 8 queen problem. Then a small weekend project, a sudoku solver (the hard part was to work with people you never met before tbh).

The 3rd week was more of the same: basic struct/enums exercises, then linked list the next day, maybe static and other keyword in-between. I used the Btree day to understand how linked list worked (and understand how did pointer incrementation and casting really work), and i don't remember the last day (i was probably still on linked lists). Then a big, 5-day project, and either you're in, or you're out.

I assure you, strings were not the hardest part. Not having any leaks was.

Re: Git's list of banned C functions

#185

Post by Communitivity »

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.

I remember an entire lecture about the use and abuse of sprintf and related functions as a means of exploit. Yeah, when you delve into the internals of C you find things that are terrifying if you are concerned about reliability, security, or performance. The same is true though for many languages. The problem is, as is often the case, the Iron Triangle: good, fast, cheap - pick two. Different sections of the language are written by developers under different constraints and pressures, which leads to different choices. In my experience every language implementation has at least one area that was done quickly for expediency or done poorly because no one else was able to (or wanted to) work on it.

Re: Git's list of banned C functions

#186

Post by maerF0x0 »

crimper wrote: post #140
maerF0x0 wrote: post #62

Earlier quoted context omitted.

Not that I dont believe there are any, but I'd love to hear your perspective... Go (golang)

channel programming and the races caused by closing channels. channels seem nice and easy until they don’t. the whole var/:=/= assignment combined with the error handling style and the shorthand is another one

yeah the lack of determinism in selecting a channel can be tricky for causing bugs where order matters. Luckily in smaller cases you're likely to encounter them as flakey tests (eg 1/2 the time)

   select {

       case

Re: Git's list of banned C functions

#187

Post by burnished »

mkipper wrote: post #86
rodgerd wrote: post #74

Earlier quoted context omitted.

There's far more critical code in the world running on COBOL and s3[79]0 assembler. COBOL is vastly more important than C.

citation needed I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.

COBOL is still used in many banking systems such as ATMs. These are 'critical' systems by most any definition of the word 'critical'.

Re: Git's list of banned C functions

#188

Post by notaplumber »

attractivechaos wrote: post #123
kzrdude wrote: post #111

Earlier quoted context omitted.

You have found the answer - strlcpy is not a replacement for strncpy at all (it's arguably a safer version of strcpy), and git people didn't invent this, it's the existing BSD strlcpy interface.

Thanks for the confirmation. But my concern remains: they banned strncpy without a proper replacement. In addition, I didn't know the extra restriction of strlcpy until today (I have never used it before because it is not conforming to C99/POSIX). I might have fallen into this trap.

The problem is the actually often the opposite, in the real world many treat strncpy as if it behaves like strlcpy. Note that strlcpy is equivalent to:

    snprintf(buf, sizeof(buf), "%s", string);
strlcpy is on track for future standardization in POSIX, for Issue 8, but even as a de facto standard, it exists in libc on *BSD, macOS, Android, Solaris, QNX, and even Linux using musl.

https://www.austingroupbugs.net/view.php?id=986#c5050

But you're correct in that it is not a replacement for strncpy because no code should be using strncpy.

Re: Git's list of banned C functions

#189

Post by cb321 »

Camillo wrote: post #130
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 the problems with C descend from a common root, the decision to use bare pointers (memory addresses) as the basic way to refer to strings, arrays etc. If they had used a {pointer, size} pair instead, it would have avoided all of these string problems, most buffer overflows, even the GTA Online loading problem that was on HN recently.

For what it's worth, while what @Camillo says is both true and important, people usually do not mention the trade offs involved or why that decision was attractive at the time.

These days (ptr,size) is probably 16 bytes -- longer than almost all words in the English language (the scrabble SOWPODS maxes out at 15). A pointer alone is 8B. Back at the dawn of C in 1970, memory was 7..8 orders of magnitude more expensive than today..(about 1 cent per bit in 1970 USD). (Today, cache memory can be almost as precious, but I agree that the benefits of bounded buffers probably outweigh their costs.)

8B pointers today are considered memory-costly enough "in the large" that even with dozens of GiB machines common, Intel introduced an x32 mode to go back to 32-bit addressing aka 4B pointers. [1] There are obviously more pointers than just char* in most programs, but even so.

Anyway, trade offs are just something people should bear in mind when opining on the "how it should be"s and "What kind of wacky drugs were the designers of language XYZ on?!!?".

[1] https://stackoverflow.com/questions/9233306/32-bit-pointers-...

Re: Git's list of banned C functions

#190

Post by zwieback »

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…

The stack thing was always the big worry for me. Without a comprehensive static code analysis tool that's hard to do. And runtime stack checking adds quite a bit of overhead, especially if you also have to worry about running on the interrupt stack and possibly switching.
Post reply on HN