[stiff]

Looks like Git has its own string type:

https://github.com/git/git/blob/master/strbuf.h

https://github.com/git/git/blob/master/strbuf.c

See this for the story of why strncpy/strncat are insecure:

https://en.wikipedia.org/wiki/C_string_handling#Replacements

[adamnemecek]

Like essentially all C programs.

[segfaultbuserr]

Every C programmer has his/her own standard library...

[r3trohack3r]

I wonder about this every time I read C.

There is talk about npm/rust having massive dependency trees (and they do) because it makes taking on dependencies too easy. But I feel like C is on the opposite side of the spectrum, where managing dependencies is difficult so every C code base is rolling it’s own version of everything.

C also has an expansive standard library but it hasn’t offset re-invention of that stdlib in the ecosystem. I just see those implementations trapped inside code bases that don’t export them in a consumable way for other projects...

Personally I love writing C but rarely do because dependency management makes innovation in those code bases so time consuming for me.

[jancsika]

It's bad that C devs have rolled their own awful, buggy custom solutions.

However, here's the upshot-- that awful, buggy, custom solution is guaranteed to remain compatible with the codebase that contains it. You won't find a single instance where such a dev "improved", "refactored", "optimized", or "modernized" that awful, buggy code in a way that stopped the rest of the code from working and then shipped that broken blob of junk. And if you did find that, there's no way they'd convince the rest of the devs that this is a useful thing to do in the interest of "moving forward" or whatever.

On the other hand you'll find zillions of dollars spent on systems to keep dependency management tools from causing exactly that problem.

Just to give a real-world example-- a user reported that an abandoned C++ plugin wasn't working. We did a race:

1. Three devs try to get a single C++ dependency of that plugin to work cross platform (OSX, Windows, Linux).

2. I tried to port the C++ plugin to a C plugin with no deps.

By the time I ported, tested, and shipped, those three devs were tracking down a bug with the build script of the C++ dependency on Windows.

Edit: granted the plugin itself is only about 2000 lines of code.

[ShinTakuya]

Regarding remaining compatible, I would argue that this is why modern languages implement lock files and version pinning. If you don't like a particular change but need some extra functionality or a security fix you can fork the relevant libraries or extend the functionality with an extra self written library.

[riquito]

It's not a guarantee that it will work, it's not that rare to encounter a minor/patch version in a library that introduced some subtle incompatible change (usually unbeknownst to the author)

[Volt]

It still sucks. I have a few Haskell projects from a few years ago that I wanted to compile on another system. So I froze the dependencies, moved the project, and tried to build. Solver failed. I gave up.

[rubber_duck]

You had the unfair advantage of working on your own :)

[adamnemecek]

This is a C++ dependency manager problem though.

[Volt]

That's the point

[timq]

That was very true for a long time. But now with cmake and a package manager like hunter, it became quite easy and pleasant to work with dependencies. ExternalProject_Add() may also work.

[segfaultbuserr]

Creating a lightweight library would make C programming much more productive, and I'm sure many have tried, but I wonder why none of them see widespread applications, instead of writing some half-baked, ad-hoc helper functions.

One reason, I guess, is the diverse range of applications of C, another reason is the lack of advanced features like generics and templates.

But it would still be useful to create a simple library, intended for Unix-like platforms (beyond the BSD extension of stdlib). So it's more of a cultural problem?

[timq]

If I had to guess why there are no such lightweight library, it is because when somehow the library API doesn't provide what you want, you cannot hack the library itself easily. If you import the source code you may have trouble building it, and maintening such "patch" is not a lot of fun.

[segfaultbuserr]

Yes. I guess the fact C doesn't have advanced features like generics and templates probably have made the problem worse, making it difficult to create a "drop-in" API.

[goatinaboat]

There is a powerful C library that covers nearly all use cases, you merely need to write a configuration file for it. Perhaps you’ve already heard of it? Tcl.

[StreamBright]

All of them are null pointer exception & segfault free I bet.

[sfkdjf9j3j]

Due to the language's design, C programs are in fact guaranteed to be free of exceptions.

[teddyh]

Except SIGFPE.

[segfaultbuserr]

I nominate your comment for the HN comment of the day.

[StreamBright]

Nitpicking but you are right. Null pointer bugs (null pointer dereference to be precise) are all over the place in C though.

https://stackoverflow.com/questions/4007268/what-exactly-is-...

[zsrxx]

What's a good library for this kind of boilerplate? A lightweight one if possible, i.e. not fucking glib

[vmsp]

Salvatore Sanfilippo, from Redis fame, has a nice one https://github.com/antirez/sds.

[chucksmash]

Thanks for linking this, it's always good to see how very strong engineers solve problems. Never in a million years would this approach have occurred to me. For the interested, the README in the linked repo is done well and clearly explains the approach itself as well as pros and cons. This also reminded me that I've been meaning to watch antirez' "Writing System Software"[0] videos on YouTube for quite a while now, so thanks for that too.

[0]: https://www.youtube.com/playlist?list=PLrEMgOSrS_3fghr8ez63x...

[megous]

I'd rather make it explicit that returned/passed value is something other than a regular zero terminated string. Otherwise you can easilly make a mess, if you pass zero terminated string to a function that expects some special bytes in the memory before the pointer.

[doboyy]

I do this, but I like to just return the actual struct and also avoid typedefing pointer semantics. Can double as a dynamic array too. It's true. We all have string libraries...

[zsrxx]

I haven't looked much so I can't comment on the quality of the library but that hairdo is glorious. Props to Salvatore!

[tlb]

There are far too many. APR is a solid choice -- very portable, well-tested, and fast. It uses memory pools a lot, which work well for many styles but not everything.

See https://apr.apache.org/docs/apr/1.7/modules.html

[emmelaich]

This is a good place to start:

https://dwheeler.com/secure-programs/3.71/Secure-Programs-HO...

[seamyb88]

What's wrong with glib, other than not being lightweight? I love glib.

[CameronNemo]

libbsd has strlcat and strlcpy.

or just use snprintf everywhere.

[adamnemecek]

Rust. Half-joking.

[commandlinefan]

That was my first thought. No strncpy? Ok,

  while (*s1 && n--)  {
    *s2++ = *s1++;
  }
  *s2 = '\0';

it is, then.

[fwsgonzo]

I don't think strncpy is the function you are looking for, either. Its for zeroing fixed-size character buffers. And it doesn't indicate problems.

https://blog.liw.fi/posts/strncpy/

[jasonhansel]

Nice. Is there a similar standalone C library for safe/sane string handling? (Please don't tell me to use C++.)

[ayosec]

https://github.com/antirez/sds

[trasz]

https://github.com/alexreg/libsbuf