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

161–170 of 329 posts

Re: Banned C standard library functions in Git source code

#161

Post by mort96 »

saagarjha wrote: post #140
jpjuni0r wrote: post #114

Earlier quoted context omitted.

I'm curious how sscanf is considered bad?

scanf(“%s”, …) can cause a buffer overflow.

It sucks that there's no scanf("%.*s"), where you give the buffer length as a separate argument. The fact that it's in a string literal also makes using a compile-time constant really ugly.

Re: Banned C standard library functions in Git source code

#163

Post by jjuhl »

saagarjha wrote: post #136
chris_wot wrote: post #92

Earlier quoted context omitted.

I've always wondered why goto is actually considered harmful. I really should read the original paper by Djikstra...

It encourages spaghetti code.

[RAII](https://en.cppreference.com/w/cpp/language/raii) to the rescue..

Re: Banned C standard library functions in Git source code

#164

Post by microtherion »

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?

Not enough memory at *p. The loop performs the exact same function that strcpy does, and some people just write it out by hand.

Re: Banned C standard library functions in Git source code

#165

Post by Dylan16807 »

bhk wrote: post #90
asveikau wrote: post #37

Earlier quoted context omitted.

A C programmer reading this list knows exactly why they are there. It is not at all a controversial list. Edit: I guess some down voter doesn't believe me but it continues to be true. They are all string functions. Most of them do not take an output buffer size, so a source string exceeding the destination buffer will overflow. Others, like strncpy, take an output buffer size but will not null terminate when exceeded…

If every C programmer knew, then there would be no need to ban them

That's not true. People don't staunchly avoid situations that have pointless sharp edges. Putting up caution tape, despite everyone being aware of the danger, is very often a useful activity.

Re: Banned C standard library functions in Git source code

#167

Post by userbinator »

rkangel wrote: post #144
userbinator wrote: post #141

Good to see the list is short and relatively sane compared to other "banned function" lists. Unfortunately, "too easy to misuse" is a slippery slope, and gets(), which is probably the best example of a function which is really broken by design, isn't on that list. I'm surprised that "complicate audits" is given as a reason, because isn't this something static analysers (and I mean ones that actually analyse data/code…

C aliasing rules can very quickly make "following the data back to its origin" very difficult.

Theoretically it's equivalent to the Halting Problem, but in practice I've not seen such difficulty; if aliasing does become a problem to the extent that following dataflow is difficult, I suspect there are already far deeper design flaws in the codebase.

Re: Banned C standard library functions in Git source code

#168

Post by ncmncm »

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.

The (more-or-less) sensible replacement is std::string. Adoption has been spotty, for practical, ideological, and fetishistic reasons.

The first step is to compile the C program with a C++ compiler. Next, start making improvements. If you skip the first step, the ceiling on improvements is limited.

Re: Banned C standard library functions in Git source code

#170

Post by pjmlp »

dblock wrote: post #13

Windows programmers are familiar with StrSafe.h, https://en.wikipedia.org/wiki/Strsafe.h and https://github.com/dotnet/coreclr/blob/master/src/pal/inc/st... which go a lot further. Also found https://github.com/mubix/netview/blob/master/banned.h on Github with a better list.

Additionally we get to enjoy bounds checked arrays(std::...), and iterators on debug builds, with possibility to selectively enable them in release mode.

While Windows by all means still has its security issues, the toolchain is much more security oriented than most FOSS alternatives thanks to the Windows XP wake up call.

Android and ChromeOS are probably the mostly locked down alternatives on the FOSS space.

Post reply on HN