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

131–140 of 639 posts

Re: Git's list of banned C functions

#131

Post by capableweb »

orf wrote: post #92
masklinn wrote: post #77

Earlier quoted context omitted.

> Why make it harder Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. > why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made? Because that doesn't really matter.

> Because that doesn't really matter. Ok, so maybe rather than have this file we should run “git log | grep BANNED” and build a list of functions from that? Or maybe we could change all error messages to be “go look at the commit history to work out why this happened”. No? Maybe putting context in source files (or better yet, an error message!) rather than in a side channel like the commit message has value when it c…

Your source code should describe what the program should do today. It should not contain all historical artifacts about your source code, as it'll grow to big and unmanageable then. Instead, use Git to store temporal information, data that is about change and reasoning behind it. Git is basically a timeline, instead of hard facts of today.

That's why it makes sense to describe the background and reasoning behind a change in a Git commit, instead of inside your source files as comments.

Re: Git's list of banned C functions

#132

Post by underwater »

masklinn wrote: post #77
orf wrote: post #43

Earlier quoted context omitted.

Why make it harder, and why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made?

> Why make it harder Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. > why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made? Because that doesn't really matter.

Code is evergreen, whereas a git commit represents a change at a single point in time. It will always be limited by the knowledge the author had available to them.

The commit message from 2020 with suggested alternatives might very well go stale. Does the author go and force a noop commit so they can document new best practice in a new commit message?

Re: Git's list of banned C functions

#133

Post by _the_inflator »

detaro wrote: post #109
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.…

Because individual libraries choosing to change quickly is comparable to language stability how? The relevant comparison would be "run a 3y old react app (or a 20 year old website using JS) in a modern browser or interpreter"

Yes, and it would still run fine I guess. I think only eval() changed over time. APIs and so on are still the same except for some Netscape stuff.

Re: Git's list of banned C functions

#134

Post by nwmcsween »

smasher164 wrote: post #32
dahfizz wrote: post #23

Earlier quoted context omitted.

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

From the commit message: If you're thinking about using it, consider instead: - strlcpy() if you really just need a truncated but NUL-terminated string (we provide a compat version, so it's always available) - xsnprintf() if you're sure that what you're copying should fit - strbuf or xstrfmt() if you need to handle arbitrary-length heap-allocated strings

strlcpy is safer but effectively running strlen(src) every call is a good wtf

Re: Git's list of banned C functions

#135

Post by pjc50 »

dev_tty01 wrote: post #72
drfuchs wrote: post #6

It would be nice if the error messages generated would suggest replacement functions that they deem appropriate. I see that I'm not supposed to use gmtime, localtime, ctime, ctime_r, asctime, and asctime_r; but what do they think I should use?

It would be even nicer if it redefined the call to a safe version and then generated a warning message informing the programmer of the substitution.

You can't do that because the semantics are different in most cases.

Re: Git's list of banned C functions

#136

Post by capableweb »

jorl17 wrote: post #125
grncdr wrote: post #27

Earlier quoted context omitted.

It seems pretty safe to assume a developer contributing C code to git itself would know how to use git blame (or the GitHub interface for it).

I find it highly backwards that documentation on "what to use instead of X" is in the commit message disabling X. One _might_ do it and might remember to do it, but IMO it makes absolutely no sense for this not to be documented properly in code, as suggested by OP. By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit tha…

> By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit that made it for the documentation". Of course this could be done, but it sounds ridiculous even typing it out.

Yes, exactly. You want to understand how a codebase changed and evolved over time? Git is your friend. If you want the facts of the code today? The source code is your friend. That's why the way Linux and Gits Git repository method of storing history makes sense. See also https://news.ycombinator.com/item?id=26348965

Try navigating the Git codebase with a git-blame sidebar (probably VS Code has that somewhere) so you can see the history of the source files. If you wonder why something is what it is, you can checkout the commit that last modified it. Or go even further backwards and figure out in the context it was first added. If you truly want to understand a change, a git repository with well written git messages is a pleasure to understand and dig into.

Re: Git's list of banned C functions

#137

Post by ironmagma »

dangerbird2 wrote: post #63
ironmagma wrote: post #21

Earlier quoted context omitted.

Yeah, there is a culture of complacency in C probably owing to the enormous historical baggage of legacy code that has to be supported and the blurred line between stdlib and system call.

It's not really complacency: it's that the standard library is intentionally minimalistic to maintain portability and backwards compatibility. If you want sensible string handling, it's usually best to use a high level utility library like GLib( https://developer.gnome.org/glib/stable/ ) or Apache Portable Runtime( http://apr.apache.org/ ), or roll your own safe string type (preferably non-null terminating)

Why do you need backward compatibility with a compiled language? Other languages like Rust and JavaScript (even) avoid that with a pragma tag on the source.

Re: Git's list of banned C functions

#138

Post by frob »

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?"

Re: Git's list of banned C functions

#139

Post by colordrops »

drfuchs wrote: post #6

It would be nice if the error messages generated would suggest replacement functions that they deem appropriate. I see that I'm not supposed to use gmtime, localtime, ctime, ctime_r, asctime, and asctime_r; but what do they think I should use?

Also, why the functions are banned.

Re: Git's list of banned C functions

#140

Post by crimper »

maerF0x0 wrote: post #62
SavantIdiot wrote: post #57

Earlier quoted context omitted.

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…

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

Post reply on HN