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

Git's list of banned C functions

github.com

Post reply on HN
Print view View original

381–390 of 639 posts

Re: Git's list of banned C functions

#381

Post by userbinator »

unbalancedevh wrote: post #249
frob wrote: post #138

Earlier quoted context omitted.

As someone who learned C as their first language, strings in every single language after that have felt like cheating. "What? You mean I can type an arbitrary string and it works? I don't need to worry about terminators or the amount of memory I've allocated? You can concatenate two strings with +?!? What is this magic?"

It always makes me wonder if there's some hidden overhead that I'm absorbing. When I program in C I feel like I know a lot better what the generated instructions will be. Using higher-level languages for embedded programming where resources are tight makes me uncomfortable.

There certainly is --- it's very easy to make accidentally quadratic (or worse) algorithms in languages where data structures automatically resize themselves to their contents.

Re: Git's list of banned C functions

#382

Post by Tarragon »

tomjakubowski wrote: post #239
gilbetron wrote: post #114

Earlier quoted context omitted.

Meh, most of us understood the sharp edges of strings pretty well. Before, we'd check the len of strings before strcpy, strncpy let us do it without doing that, and just slap a 0 in if needed. Safe? No. Better? A bit. Do I ever want to do string manipulation again with C? Nope.

Understanding the sharp edges is one thing. Being able to avoid them in practice is another. The history of memory safety problems in C string handling, especially involving strcpy/strncpy, strongly suggests to me that they're unavoidable even for C programmers who are skilled, knowledgeable, and experienced.

As an embedded programmer mostly working with C who considers themselves skilled, knowledgeable, and experienced...

I agree.

Re: Git's list of banned C functions

#383

Post by wongarsu »

closeparen wrote: post #181
lmilcin wrote: post #67

To respond to some of the comments. It is not that there is anything intrinsically wrong with these functions. You can technically use all of them and I have been using all of them, safely, for decades. The issue is they are huge traps to the point that in a larger piece of software one can say "well, it's just not worth it". You can go much, much, much further than that. In couple embedded projects I worked some of…

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

> Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

That depends on the OS. Linux lies (overcommits), Windows doesn't. In embedded it's more typical to have a special OS like VxWorks or FreeRTOS that don't lie to you, or to have no OS at all (like basically every arduino project)

Re: Git's list of banned C functions

#384

Post by rtpg »

paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

The string stuff is kind of the original sin, but to be honest almost all programming environments have massive footguns when it comes to times/dates. Python's datetime story is _extremely_ painful to deal with. Try doing .... I dunno, anything apart from getting the current time and doing an ISO format of a Javascript Date object.

I think stuff has kinda gotten better, but while Unicode had emoji to kinda save the day, dates never had this moment and we're still suffering through major messes on a daily basis because of it.

Re: Git's list of banned C functions

#385

Post by kortex »

bobbyi_settv wrote: post #258
munchbunny wrote: post #193

Earlier quoted context omitted.

The prefix approach turns the neat "strings are just character arrays are just pointers" pattern into something a lot more clunky, because now you've got this really basic data type that is actually a struct and now you have to have an opinion on how wide the length value is and short strings get a lot of memory overhead in just lengths, and so on. In hindsight, I think the complexity is worth the safety, but I could…

It doesn't just buy safety. It also makes it possible to include null bytes inside of strings.

This is the part that boggles my mind. It's not like fat pointers just didn't exist at the time. You need fat pointers any time you do anything with dynamic non-string binary data.

Null is always 1 byte minimum so at best you save size_t-1 bytes per string. Ignoring clever structures like LEB128 varint length.

This is a classic case of "simple is actually complex". How many billions of dollars has null terminal strings cost? Hope that 3 bytes of overhead per string saved is worth it.

Re: Git's list of banned C functions

#386

Post by AaronFriel »

rtpg wrote: post #384
paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

The string stuff is kind of the original sin, but to be honest almost all programming environments have massive footguns when it comes to times/dates. Python's datetime story is _extremely_ painful to deal with. Try doing .... I dunno, anything apart from getting the current time and doing an ISO format of a Javascript Date object. I think stuff has kinda gotten better, but while Unicode had emoji to kinda save the d…

Python's dates are very unlikely to cause quadratic or exponential performance dips, segfaults, or remote code execution vulnerabilities. (And JS now has Date#toISOString, since ES5.)

C's string manipulation functions are a regular source of the worst vulnerabilities in software.

Even if they're in the same category of legacy cruft, they're not even remotely in the same magnitude of consequences.

Re: Git's list of banned C functions

#387

Post by throwaway3neu94 »

__turbobrew__ wrote: post #334
paganel wrote: post #267

Earlier quoted context omitted.

This heavily filters for people who have had experience with programming in high-school or even before that, there's no way for a programming novice to pass that grueling routine. And then people rhetorically ask themselves why students coming from economically disadvantaged households are under-represented in this industry (one of the best paying industries in this time and age). Stuff like that has got to change.

I went through a very similar gauntlet in my first undergrad computers class. I didn’t know anything about programming or linux, but it was fine. I think the filter is more effective for finding those who can quickly adapt, learn, and grok a methodical mindset. Not necessary characteristics to be a programmer, but necessary characteristics to excel at programming.

Does it though, or is it more survivorship bias and maybe lucking into finding someone who will spend hours mentoring you?

I've mentored quite a few first semester students (in my spare time, to help. Not as a job) and there is no way some of them would've passed without serious help.

At some point I used to think privately that CS should have a programming test as an admission exam, because these students did drag everyone down. If medicine and law have admission restrictions, why not CS too?

But I have changed my opinion because I think everyone deserves a real opportunity, and our school system does not provide a level playing field sadly. (Also the medicine & law admission criteria are GPA based and that is the last thing I'd want for CS.)

Anyway the real filter was always maths.

Re: Git's list of banned C functions

#388

Post by lmilcin »

wongarsu wrote: post #383
closeparen wrote: post #181

Earlier quoted context omitted.

How often does the dynamic allocation rule lead to an ad-hoc allocator appearing inside the program? Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use.

> Also doesn’t the OS lie? I thought the memory wasn’t really physically assigned until first use. That depends on the OS. Linux lies (overcommits), Windows doesn't. In embedded it's more typical to have a special OS like VxWorks or FreeRTOS that don't lie to you, or to have no OS at all (like basically every arduino project)

Linux doesn't lie, it is just probably not doing what your simplified view of memory allocation is.

On Linux memory allocation is basically assigning range of address that may or may not be backed by pages in physical memory.

This allows doing a lot of interesting and useful stuff.

If you really want the memory for some reason (for example you need to guarantee your operation finishes without running out of memory), you need to touch the pages or force them in some other way (for example using mlock()).

It is just that developers are mostly oblivious how memory management works on Linux and then are surprised that it doesn't exactly do what they want.

Most people I work with can't tell how much memory is available on a Linux box if their life depended on it.

Re: Git's list of banned C functions

#389

Post by loeg »

jchw wrote: post #45
paultopia wrote: post #17

Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.

Unfortunately, much of the pain with C surrounds dealing with strings. It’s been a bit of a theme on Hacker News for the past few days, but it’s actually a pretty good spotlight on something I feel is not always appreciated - strings in C are actually hard, and even the most safe standard functions like strlcpy and strlcat are still only good if truncation is a safe option in a given circumstance (it isn’t always.) (…

Truncation, even if it is wrong in an application logic sense, is strictly superior to UB (and in practice, buffer overruns, which can be exploitable). That's the main benefit of strlcpy/strlcat. It is certainly possible to construct a security bug due through truncation! But it is much more common to have security bugs from uncontrolled buffer overruns.

Re: Git's list of banned C functions

#390

Post by mkipper »

burnished wrote: post #187
mkipper wrote: post #86

Earlier quoted context omitted.

citation needed I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.

COBOL is still used in many banking systems such as ATMs. These are 'critical' systems by most any definition of the word 'critical'.

Sure. But is there far more critical COBOL than C out there?

The OS kernel for nearly every PC and server on earth is written in C.

Almost every electronic device on earth complicated enough to require software is probably running at least some firmware written in C.

I think those both outnumber ATMs by a hefty margin.

Post reply on HN