Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Banned C standard library functions in Git source code

github.com

Post reply on HN
Print view View original

261–270 of 329 posts

Re: Banned C standard library functions in Git source code

#261

Post by emmelaich »

codedokode wrote: post #210

What surprises me in C developers is that C exists for probably 40 years but they still don't have proper strings (not just pointers). In many cases there is no large performance penalty for storing string length, and checking it, but they still use pointers or a separate pair of variables for pointer and buffer size instead of single object.

C has _only_ pointers for variable size things, not just strings.

Roughly speaking C vars are either known fixed length, or accessed via pointer. There is nothing else.

(except arrays -- which are mostly pointers)

Re: Banned C standard library functions in Git source code

#262

Post by uncletaco »

floatboth wrote: post #232
uncletaco wrote: post #186

Earlier quoted context omitted.

Tangential but the fact that I had to open up the machine and remove a screw to completely replace ChromeOS with linux bothers the fuck out of me.

That's how secure boot should work. Replacing the root of trust should require serious physical access that can be tamper-evident. And yeah, out of the box, the trust is with the vendor — who else would be trusted in a device that doesn't have an owner yet?

I never thought of that. And it makes a lot more sense in that context.

Re: Banned C standard library functions in Git source code

#263

Post by jraph »

sooheon wrote: post #244
mrbungie wrote: post #240

Earlier quoted context omitted.

No flaw with math/stats here, that can actually happen. I think you're confusing average/mean with median (50-percentile). PS: I'm not sure where he's getting his numbers though

I'm 99% sure that was tongue in cheek.

I think that it would have been even funnier to say that 99% of developers and 99% of drivers are better than the median, but I only figured this thanks to your parent's comment.

Re: Banned C standard library functions in Git source code

#264

Post by bhk »

userbinator wrote: post #148
bhk wrote: post #85

Earlier quoted context omitted.

Synchronous reentry is a problem. Say some loop using strtok calls a function... how do you know that that function doesn't use strtok (or call another function that does...). Any use of non-const static variables in general has this problem, and strtok is just one example.

how do you know that that function doesn't use strtok (or call another function that does...). The same way you know a lot of other things about the codebase: By reading and understanding it. Given what strtok() is used for, it's almost always going to be working on a single context at any one time.

First, many C projects are libraries that are written for reuse in other programs. So "the codebase" is an arbitrary, unknowable thing. We don't have the ability to look at all the other code that will eventually coexist in the same process.

Second, code changes over time. Assuming you inspect 100 lines of code to ensure that they don't call strtok() ... do you sprinkle comments all over as a warning to future programmers not to add any calls to strtok()?

Finally, assuming we could evaluate all of the code in a program at once, it is impractical to build non-trivial programs that way. Instead, we rely on contracts. The idea is that if a caller conforms to its end of the contract, the callee will conform to its end. This allows us to reason about correctness of some code without reading all the other code in the universe and thinking through all the potential code paths. Any function using strtok() would be presenting a rather ugly contract clause "this function destroys strtok's static state". Even worse, such a clause would be contagious, infecting any client of that function, and so on.

Re: Banned C standard library functions in Git source code

#265

Post by smcameron »

ryandrake wrote: post #59
alister wrote: post #26

I'm glad to see that setjmp() and longjmp() are still allowed. I'm just kidding by the way. For those C programmers who haven't encountered these before, it is a powerful way to do a "goto" in C. Powerful in the sense that you can jump anywhere, not limited to the same function. If it's used at all these days, it's used for exception handling. More info: https://en.wikipedia.org/wiki/Setjmp.h

I think reasonable people can debate this one. setjmp()/longjmp() are very useful when working with libpng [1] and jpeglib [2], as you mentioned, as a crude exception handling mechanism. I have seen these functions used in production safely for that purpose. I can imagine other horrible uses for them though. Unlike things like strcpy() which are security-holes-by-design, setjmp()/longjmp() should be in a "carefully c…

> very useful when working with libpng

There is no reason libpng needed to use setjmp as part of its API, and that it does so is (I hope) widely regarded as a bad decision. It's "useful" only in so much as that is the API it defines, but there is no reason that this had to be the case, and simply returning an error code would have been very very much preferable.

Re: Banned C standard library functions in Git source code

#266

Post by ShinTakuya »

riquito wrote: post #258
ShinTakuya wrote: post #256

Earlier quoted context omitted.

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.

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)

That's literally the purpose of the lock file. The lock file locks the entire dependency tree. So unless you're bumping versions or you fail to save the lock file, the entire dependency tree's versions will remain the same.

>some subtle incompatible change

In statically typed languages this normally isn't an issue. Of course I'm aware that logic can also be changed, but in that case it's up to you to write appropriate tests (or just don't bump the versions of your libraries without a good reason).

Re: Banned C standard library functions in Git source code

#267

Post by _kst_ »

cyphar wrote: post #180
winter_blue wrote: post #175

Earlier quoted context omitted.

It doesn’t — I was wrong. I was digging through its source code, and it turns out it isn’t memory-safe after all. Here’s the source code for stpcpy: https://github.com/ifduyue/musl/blob/master/src/string/stpcp... If dest is too small in the function linked to above, musl’s stpcpy will happy cause a buffer overflow. Don’t know how or from where I got the impression that musl was a “safer” alternative to libc.

The API of strcpy() is unsafe by design. The only way to make it safe is to not use it, and it's not musl's (nor glibc's) fault that this is the case. musl is interesting for a variety of other reasons, but being more memory safe isn't really one of them.

strpy() is safe when used safely. That means that you've confirmed that the target is big enough.

For example, there's no way this can fail:

    char s[10];
    strcpy(s, "hello");
The problem is that it can also be used unsafely, and except in the simplest cases it's difficult or impossible to tell whether a give usage is safe.

By contrast, gets() (which isn't even in the language anymore) is inherently unsafe, because you can't control what will appear on standard input.

Re: Banned C standard library functions in Git source code

#268

Post by kijiki »

alister wrote: post #26

I'm glad to see that setjmp() and longjmp() are still allowed. I'm just kidding by the way. For those C programmers who haven't encountered these before, it is a powerful way to do a "goto" in C. Powerful in the sense that you can jump anywhere, not limited to the same function. If it's used at all these days, it's used for exception handling. More info: https://en.wikipedia.org/wiki/Setjmp.h

It is also the only way for an xlib program to survive losing its connection to the X server. xlib will let you register a callback to handle loss of connection with XSetIOErrorHandler, but unconditionally calls exit() after your callback returns. Which is extremely anti-social behavior for a library, but that is what it does.

So the solution is to setjmp before each call to an X function that might notice the connection is closed, and longjmp out of the error callback. Ugly, but it works.

These days, you should really just use XCB, or even Wayland.

Re: Banned C standard library functions in Git source code

#269

Post by Stratoscope »

cmroanirgo wrote: post #238
CamperBob2 wrote: post #194

Earlier quoted context omitted.

Fortunately, 99% of developers, like 99% of drivers, are better than average.

> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...

You've never been on a project that was 80% done and 80% to go?

Re: Banned C standard library functions in Git source code

#270

Post by doboyy »

vmsp wrote: post #62
zsrxx wrote: post #38

Earlier quoted context omitted.

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

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

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...
Post reply on HN