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

191–200 of 639 posts

Re: Git's list of banned C functions

#191

Post by dpatterbee »

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

Only close channels when trying to tell the receiver that you're not sending more data. Otherwise let the garbage collector deal with it. Channels seem easy until they don't until they do again in my experience.

Don't understand your second point.

Re: Git's list of banned C functions

#192

Post by alcover »

attractivechaos wrote: post #66
lights0123 wrote: post #48

Earlier quoted context omitted.

https://github.com/git/git/commit/e488b7aba743d23b830d239dcc... Yes: > we provide a compat version, so it's always available

This gets me interested. Link [1] below shows their implementation of strlcpy(). This is a questionable implementation. With strncpy, the source string "src" may not be NULL terminated IIRC. The git implementation requires "src" to be NULL terminated. If not, an invalid read. EDIT: according to the strlcpy manpage [2], "src" is required to be NULL terminated, so strlcpy imposes more restrictions and is not a proper r…

Agreed. It's O(n) inefficient. I guess looping though chars up to `size` would perform better on average.

I see this `strlcpy` recommanded everywhere.

Re: Git's list of banned C functions

#193

Post by munchbunny »

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.

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 see why it felt more elegant to use null-terminated strings at the time.

Re: Git's list of banned C functions

#194

Post by ironmagma »

hctaw wrote: post #179
ironmagma wrote: post #167

Earlier quoted context omitted.

Good point, thanks. Could the headers contain the pragmas?

That assumes you have a header, which only exists at compile time for the developer. The running program knows nothing about it.

Why would a program need to know (e.g.) the details of what system calls or stdlib functions that a procedure it invokes uses? Aren’t C functions pretty well separated from each other except for the odd signal handler and assuming a stable ABI? In my view most of the issues with C are semantics within the function blocks.

Re: Git's list of banned C functions

#195

Post by kazinator »

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.

gmtime is just not thread-safe that's all, since it returns a static structure; gmtime_r is not banned.

Re: Git's list of banned C functions

#196

Post by orwin »

viklove wrote: post #100
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.…

It amuses me that HN hates JS so much, that even a topic about problems with C turns into a JS-bashing thread. Also, I just want to remind you that JS isn't just React. There are plenty of libraries written in C that introduce breaking changes over the course of 3 years. Nothing will stop people from finding ways to complain about JS though, I know. The hate-boner is very real.

I think most people on HN like Javascript, or at least its idea? I mean, its a very C-like functionnal language, especially since ES6 put Js on the right road (for me at least)?

Re: Git's list of banned C functions

#198

Post by kazinator »

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.

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

Re: Git's list of banned C functions

#199

Post by selfhoster11 »

JoeAltmaier wrote: post #175
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.

Hey, languages used length,blob even when C was invented. HP Access BASIC used that kind. It was a limitation, because they chose a byte length (to save space). So strings up to 255 characters only. It was decades before folks were comfortable with 32-bit length fields. And that still limited you to 4GB strings. In the bad old days, memory usage was king.

The funny thing is that you can just use the topmost bit of the length to indicate that the string length is >127, and chain as many length bytes as you want before you begin the string proper (to save space). It would be still a better encoding than a null at the end.

Re: Git's list of banned C functions

#200

Post by Someone »

rrauenza wrote: post #107
_kst_ wrote: post #68

Earlier quoted context omitted.

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

I never could really understand the point of strncpy()... we always end up wrapping to deal with writing an unterminated string. Was it intended for fixed length records?

Yes. strncpy was intended for copying file names into a buffer that was only zero terminated when the name was shorter than the maximum length of a file name in Unix (14 bytes. See https://stackoverflow.com/a/1454071, https://devblogs.microsoft.com/oldnewthing/20050107-00/?p=36...)

You can also use it to overwrite part of an existing string, but I think that’s a side effect of the above.

Post reply on HN