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

151–160 of 329 posts

Re: Banned C standard library functions in Git source code

#151

Post by GrumpyYoungMan »

chris_wot wrote: post #92
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've always wondered why goto is actually considered harmful. I really should read the original paper by Djikstra...

Read David Tribble's "Go To Statement Considered Harmful: A Retrospective" instead: http://david.tribble.com/text/goto.html . It contains the entire text of Dijkstra's paper and goes over its meaning in a modern context on a paragraph-by-paragraph basis. It's very well written and makes clear the "encourages spaghetti code" argument, while true at the time, applied in a era where basic control flow constructs that we now take for granted did not exist in commonly used languages.

Re: Banned C standard library functions in Git source code

#152

Post by FartyMcFarter »

Someone1234 wrote: post #150
saagarjha wrote: post #136

Earlier quoted context omitted.

It encourages spaghetti code.

Not using it can also create spaghetti code. For example the "alternatives" often suggesting for exiting a multi-tiered loop (which often add additional boilerplate, additional variables, etc that all need to be maintained/bug free).

Indeed. Despite not having actual goto, Java went out of their way to have labeled loops and the "break label_name" syntax in order to avoid this awkwardness.

Re: Banned C standard library functions in Git source code

#154

Post by sfkdjf9j3j »

StreamBright wrote: post #125
segfaultbuserr wrote: post #72

Earlier quoted context omitted.

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

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

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

Re: Banned C standard library functions in Git source code

#155

Post by dang »

vasama wrote: post #99
tlb wrote: post #93

Earlier quoted context omitted.

Here is an implementation of coroutines on top of setjmp/longjmp: https://fanf.livejournal.com/105413.html

Looks more like an implementation of undefined behaviour to me.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

Re: Banned C standard library functions in Git source code

#157

Post by segfaultbuserr »

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…

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?

Re: Banned C standard library functions in Git source code

#158

Post by stonogo »

anilakar wrote: post #82
winter_blue wrote: post #39

musl libc (an alternative libc) provides implementations of these functions that are memory-safe. (It only works on Linux though.)

Using musl as your standard library causes other problems, namely horrible Python performance and incompatibility with Valgrind.

musl is standards-compliant, so it sounds more like "using python or valgrind causes other problems,"

Re: Banned C standard library functions in Git source code

#159

Post by zsrxx »

rat9988 wrote: post #153
Koshkin wrote: post #40

> strcpy ... BANNED But they cannot ban while (* p++ = * q++); now can they.

Truly curious as I don't code in C, or any other low level language. What is the problem with it? That there might not be enough memory allocated at *q?

It doesn't stop until *p is \0, so yes

Re: Banned C standard library functions in Git source code

#160

Post by goatinaboat »

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…

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