News for hackers. Stuff that matters.
Re:Git's list of banned C functions by jdlshore on Thursday March 04, 2021 @05:43PM (#26349551)
It's a classic case of moving the complexity from one part of the system to another. "Strings are just character arrays" seems simple and elegant, but in reality is a giant mess, because strings are not just character arrays, any more than dates are just an offset from an epoch.

Human concepts are inherently messy. "Elegant" solutions just shove the mess down the road.

Re:Git's list of banned C functions by lultimouomo on Thursday March 04, 2021 @06:05PM (#26349773)
On the contrary, I think "Strings are just character arrays are just pointers" is the solution, not the problem. As with non-character arrays, you must always pair the pointer with a length. (I don't like the idea of prefixing the length because it prevents su stringing).

The problem is the null termination, which is not general to arrays (though it is sometimes used with arrays of pointers).

Re:Git's list of banned C functions by ByteJockey on Thursday March 04, 2021 @09:18PM (#26351674)
You sometimes see sentinel values used with varargs (only if they're all the same type), which is basically just an array with more boilerplate.

That being said. Length as a first parameter and the rest of the arguments being the variadic bit is also quite normal.

Re:Git's list of banned C functions by konjin on Thursday March 04, 2021 @08:18PM (#26351139)
You're just moving the complexity from strings into unsigned integers. Your strings are limited by the size of whatever you put in the head of the string.

Sure 16 exabytes sounds like a lot today, but so did 4 billion ip addresses. Differently bad is not better.

Re:Git's list of banned C functions by jdlshore on Thursday March 04, 2021 @10:51PM (#26352425)
I didn’t say anything about unsigned integers, or any specific approach to encoding strings at all, so I’m not sure what you’re trying to say here.