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

221–230 of 639 posts

Re: Git's list of banned C functions

#221

Post by julian55 »

masklinn wrote: post #69
jchw wrote: post #45

Earlier quoted context omitted.

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.) (…

> Technically C11 has strcpy_s and strcat_s "Theoretically" is the word you're looking for: they're part of the optional Annex K so technically you can't rely on them being available in a portable program. And they're basically not implemented by anyone but microsoft (which created them and lobbied for their inclusion).

They are also implemented by embedded compilers such as IAR and Keil.

Re: Git's list of banned C functions

#222

Post by varjag »

rodgerd wrote: post #74
SavantIdiot wrote: post #57

Earlier quoted context omitted.

If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew…

There's far more critical code in the world running on COBOL and s3[79]0 assembler. COBOL is vastly more important than C.

Nearly everything around you runs code that was written in C, and absolutely nothing you can actually see runs COBOL code.

Re: Git's list of banned C functions

#225

Post by [deleted] »

selfhoster11 wrote: post #199
JoeAltmaier wrote: post #175

Earlier quoted context omitted.

Hey, languages used length,blob even when C was invented. HP Access BASIC used that kind. It was a limitation, because they chose a byte length (to save space). So strings up to 255 characters only. It was decades before folks were comfortable with 32-bit length fields. And that still limited you to 4GB strings. In the bad old days, memory usage was king.

The funny thing is that you can just use the topmost bit of the length to indicate that the string length is >127, and chain as many length bytes as you want before you begin the string proper (to save space). It would be still a better encoding than a null at the end.

[deleted]

Re: Git's list of banned C functions

#226

Post by guerrilla »

matheusmoreira wrote: post #206
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.

Yeah, because of NUL-terminated strings. They cause so many problems it's not even funny. Even something simple like computing the length of the string is a linear time operation that risks overflowing the buffer. People attempted to fix these problems by creating variations of those functions with added length parameters, thereby negating nearly all benefits of NUL-terminated strings. Why can't we just have some nic…

That would be nice. You hit on the other hell with C strings: modern encodings where wchar_t and mb* are useless and replacements essentially don't exist yet with char8_t, char32_t etc. Then there's the locale chaotic nonsense [1]. A new libc starting fresh would be nice.

1. https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

Re: Git's list of banned C functions

#227

Post by kazinator »

munchbunny wrote: post #180
Blikkentrekker wrote: post #161

Earlier quoted context omitted.

> But also, "strings" and "time" are actually very complex concepts, and these functions operate on often outdated assumptions about those underlying abstractions. Even in safer languages such as Rust , there are often quæstions as to why certain string operations are either impossible, or need to be quite complicated for a rather simple operation and are then met with responses such as “*Did you know that the length…

> locale settings of environment variables Also known as "why does my code that parses floats fail in Turkey?" Also also known as the discrepancy between a string's length-as-in-bytes, its length-as-in-code-points, and its length-as-in-how-humans-count-glyphs. Strings are hard. Edit to respond to your addendum: > P.s.: In fact, I would argue that strings are not necessarily all that complicated, but simply that many…

> Why does my code that parses floats fail in Turkey

Because you, or someone, called

  fuck_my_program();
which is defined in "idiot.h" as

  #define fuck_my_program() setlocale(LC_ALL, "")
and the project is missing:

  #define setlocale(x, y) BANNED(setlocale)
Hope that helps!

Re: Git's list of banned C functions

#228

Post by cestith »

Animats wrote: post #172
stefan_ wrote: post #70

Earlier quoted context omitted.

The first thing you do is not use any strings . You'll be amazed how much you can get done in languages that aren't so obsessively centered around stringified programming.

It was a design decision of QNX that the kernel never uses strings. Everything the kernel handles is fixed length, except messages, and messages go from one user process to another. The kernel does not allocate space for them. I think they go that right. There's a QNX user process that's always present, called "proc", which handles pathnames and the "resource managers", programs which respond to path names. But that'…

There are absolutely things that can be written without string handling. Then again, there are things that can't. Not handling strings in the kernel probably was a good decision. That userland I'll bet has string handling though, to be useful to users.

Re: Git's list of banned C functions

#230

Post by PoignardAzur »

orwin wrote: post #184
InvOfSmallC wrote: post #103

Earlier quoted context omitted.

I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. The university decided to explain C to first year student without previous experience. My feedback was to do a precourse in Python to let them relax a bit with programming as a concept and then teach C in a second course.

In my school, we had two days to understand the basics of text editors, git (add, commit, rebase, reset, push) and basic bash functions (ls, cd, cp, mv, diff and patch, find, grep...) + pipes, then a day to understand how while, if/else and function calls work, then a day to understand how pointer work, then a day to understand how malloc(), free() and string works (we had to remake strlen, strcpy, and protect them).…

Ooh, the Epitech cursus. Nice.

Also, I'd say "not having segfaults" is the hardest thing to get right when you're going through that.

Post reply on HN