Git's list of banned C functions • Hacker News Board

Re: Git's list of banned C functions

#81

Post by Ar-Curunir » Thu, Mar 04, 2021, 9:31 PM UTC

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)

there's nothing inherently unportable about strings though.

Re: Git's list of banned C functions

#82

Post by qbasic_forever » Thu, Mar 04, 2021, 9:32 PM UTC

xvilka wrote: post #76

I hope, one day to see it's rewritten in a safer language.

There's a nice Go implementation of git: https://github.com/go-git/go-git

Re: Git's list of banned C functions

#83

Post by IgorPartola » Thu, Mar 04, 2021, 9:32 PM UTC

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.

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. Ever try to run 3 year old React projects using today’s React? :)

Re: Git's list of banned C functions

#84

Post by amir734jj » Thu, Mar 04, 2021, 9:33 PM UTC

Maybe instead of just writing a banned message, it should be the name of alternative function to use.

Re: Git's list of banned C functions

#85

Post by csours » Thu, Mar 04, 2021, 9:34 PM UTC

zbendefy wrote: post #3

Are there some details on whats wrong with these?

I'm pretty sure you could google each of these with the word 'dangerous'

For example: https://lgtm.com/rules/2154840805/

Re: Git's list of banned C functions

#86

Post by mkipper » Thu, Mar 04, 2021, 9:34 PM UTC

rodgerd wrote: post #74

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…

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.

Re: Git's list of banned C functions

#87

Post by [deleted] » Thu, Mar 04, 2021, 9:35 PM UTC

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.

[deleted]

Re: Git's list of banned C functions

#88

Post by icedchai » Thu, Mar 04, 2021, 9:35 PM UTC

_kst_ wrote: post #68

throwaway09223 wrote: post #37

Earlier quoted context omitted.

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.

strncpy() is not a "safer" strcpy(). It can avoid some errors involving writing past the end of the target array ( if you tell it the correct length for that array), but it's not a true string function, and it can leave the target unterminated and therefore not a valid string. http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

This is true, and many people don't realize it. I used to call a wrapper function that would always set the last byte to 0.

Re: Git's list of banned C functions

#89

Post by xondono » Thu, Mar 04, 2021, 9:35 PM UTC

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…

Anything enforcing MISRA has essentially (almost) no way of allocating memory at runtime.

Re: Git's list of banned C functions

#90

Post by oleganza » Thu, Mar 04, 2021, 9:35 PM UTC

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.

Notice that it's a giant PITA to work with any variable-length data. Because language lacks adequate means to abstract away safe fast memory access with generic types, RAII and borrow checkers. Comparing to C, both C++ and Rust (very different beasts) feel like pals of JavaScript: basic operations with dynamic strings and arrays just work™.