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

201–210 of 329 posts

Re: Banned C standard library functions in Git source code

#201

Post by baot »

jandrese wrote: post #124
ncmncm wrote: post #115

Earlier quoted context omitted.

strlcpy is a terrible alternative. I have never seen it used correctly. It takes more and uglier code to use it correctly than to use strlen and strcpy. People who use it don't bother. Finding use of strlcpy in a program is a red warning of sloppy code. There are good reasons it was kept out of glibc for so long.

I agree that strlcpy is braindamaged, but why in God's Green Earth isn't there a sensible replacement in stdlib in 2019? This shouldn't be that hard, yet the best alternative is I think snprintf, which is just so ugly. For a long time it wasn't used because compiler support was spotty, but it's been 20 years now so that shouldn't be a major issue anymore.

There is, it's strncpy_s and it was added in C11. And I know, nobody uses C11: that's a security failure.

Re: Banned C standard library functions in Git source code

#202

Post by MrStonedOne »

wincent wrote: post #91
noname120 wrote: post #21

Why is there no brief explanations in this code why each function is banned?

Because Git's own developers know to use git-blame, git-show, and write good commit messages. Comments are not the only place to store meta-info about why code is the way it is.

Git is open source, it doesn't have its own developers, every developer is "gits own developers". They really should make this more explicit.

Re: Banned C standard library functions in Git source code

#203

Post by begriffs »

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

> you can jump anywhere, not limited to the same function

Outside of the current function, yes. Anywhere, no.

Longjmp allows you to return to places you’ve already been and have saved with setjmp. Also attempting to longjmp to a function that has since returned is undefined behavior. Thus longjmp’s usual use case is like exceptions in other languages, going back up the call chain, skipping intermediate functions.

Re: Banned C standard library functions in Git source code

#204

Post by [deleted] »

megous wrote: post #104
slovenlyrobot wrote: post #74

Earlier quoted context omitted.

The trouble is how they compose with the expectations of code you don't write. It's just not normal in C to expect execution of your function to abort halfway through, and so memory leaks and broken state are almost guaranteed when they're mixed with the wrong third party library. It might work great when you wrote it, but it might not even survive the next change to the codebase, and 10 years out, who is to know wha…

longjmp will not interrupt third party code (well maybe if it uses callbacks and you use it from a callback). setjmp/longjmp will almost certainly require tracking any resource use carefully so that resources can be released at the setjmp point, when execution gets back there. I mostly use it for terminating the recursive descent parsing on error. Otherwise it gets tedious to check return values everywhere in hand wr…

[deleted]

Re: Banned C standard library functions in Git source code

#205

Post by yongjik »

mlyle wrote: post #67
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

You can build coroutines from them, too, which is really cool and useful.

I don't know why I still remember these, but if you need to build coroutines in C, ucontext.h might be a better tool:

https://pubs.opengroup.org/onlinepubs/7908799/xsh/ucontext.h...

Re: Banned C standard library functions in Git source code

#206

Post by begriffs »

Lerc wrote: post #191
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 had quite some fun playing around with it to obfuscate code. I did find that jumping to a different position in the same expression broke on a lot of compilers as soon as optimization was turned on. Here's a simple program to output a string with the characters in an unusual order. #include #include #define J(x,y) (longjmp(x,y),0) int main(int argc, char **argv) { jmp_buf j[011]; int x,X=0; signed char* i = " eehce…

> the same expression broke on a lot of compilers as soon as optimization was turned on

C is not a "try it and see" language. If you stray from the spec then things will act differently and break between compilers. Section 7.13.2 specifies that only local variables declared as volatile will have a determinate value after a longjmp.

Re: Banned C standard library functions in Git source code

#207

Post by fortran77 »

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

There really are use-cases for it, especially when implementing a Forth-style interpreter in C.

Re: Banned C standard library functions in Git source code

#208

Post by timq »

r3trohack3r wrote: post #131
segfaultbuserr wrote: post #72

Earlier quoted context omitted.

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

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…

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.

Re: Banned C standard library functions in Git source code

#209

Post by mcherm »

Lerc wrote: post #191
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 had quite some fun playing around with it to obfuscate code. I did find that jumping to a different position in the same expression broke on a lot of compilers as soon as optimization was turned on. Here's a simple program to output a string with the characters in an unusual order. #include #include #define J(x,y) (longjmp(x,y),0) int main(int argc, char **argv) { jmp_buf j[011]; int x,X=0; signed char* i = " eehce…

You, sir, have a crafty and evil mind. Well done.

Re: Banned C standard library functions in Git source code

#210

Post by codedokode »

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