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

591–600 of 639 posts

Re: Git's list of banned C functions

#591

Post by ryandrake »

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

> ~~Technically~~ Optionally, C11 has strcpy_s and strcat_s which fail explicitly on truncation. So if C11 is acceptable for you, that might be the a reasonable option, provided you always handle the failure case.

One of the big problems with C programmers is they often neglect to check for and handle those failure cases. Did you know that printf() can fail, and has a return value that you can check for error? (Not you, personally, but the "HN reader" you) Do you check for this error in your code? Many of the string functions will return special values on error, but I frequently see code that never checks. Unfortunately, there isn't a great way to audit your code for ignored return values with the compiler, as far as I know. GCC has -Wunused-result, but it only outputs a warning if the offending function is attributed with "warn_unused_result".

I'm not a huge fan of using return values for error checking, but we have the C library that we have.

Re: Git's list of banned C functions

#592

Post by CRConrad »

mariusor wrote: post #528
user5994461 wrote: post #344

Earlier quoted context omitted.

The challenge is not to write a string library, but to write a "nice" string library. Let's say, something that's easier to use and doesn't have all the footguns of the char arrays. The library you link doesn't come anywhere close to that. It's 99% like the standard library and it has the exact same issues.

I would love to see what you mean by "exact same issues". sds strings contain their lengths, so operating on them you don't have to rely on null termination, which (to my knowledge as a lower-midlevel C programmer) is the most prevalent reason why people take issue with C strings. If you mean that they're not really "strings" but byte arrays I would say that I agree, but to all intents and purposes that's what the C…

> sds strings contain their lengths, so operating on them you don't have to rely on null termination, which (to my knowledge as a lower-midlevel C programmer) is the most prevalent reason why people take issue with C strings.

Wait, haven't I seen that idea somewhere else...?

> If you mean that they're not really "strings" but byte arrays I would say that I agree, but to all intents and purposes that's what the C ecosystem considers as strings.

Aha, strings as byte arrays but with a built-in length marker.

But yeah, Pascal is sooo outmoded and inferior to C...

Sigh.

Re: Git's list of banned C functions

#593

Post by kazinator »

ineedasername wrote: post #479
MikeTheGreat wrote: post #463

Earlier quoted context omitted.

Minor detail: lecturers don't get tenure. The job role of 'professor' may be able to get tenure (I think these roles usually do) but 'lecturer' really means 'full time temporary teacher, with a contract for a specified amount of time.

I occasionally adjunct. What students call me at the beginning of the semester is always awkward: Them: "Hello Professor" Me: "Technically I'm not a professor." Them: "Okay, we'll just call you Doctor." Me: "Yeah, about that... not a doctor either." Them: "So why are we paying you?" Me: "Technically, you're paying the school. And the school is paying me... very little" Them: "Answer the question" Me: "Because I know…

For all the complicated social protocols in that neck of the woods, this would be simple in Japan. You're just 先生 (sensei) and that's it.

Re: Git's list of banned C functions

#594

Post by mcguire »

ajuc wrote: post #515
anikom15 wrote: post #462

Earlier quoted context omitted.

I’m not sure if it was the original purpose of C, or of it’s what made C popular, but compared to BASIC, processing strings in C was much faster.

Everything was faster in C - it was compiled and BASIC was interpreted. Better comparison would be between C and Turbo Pascal strings in DOS times. TP strings were limited to 255 characters but they were almost as fast as C strings, in some operations (like checking length) they were faster, and you had to work very hard to create a memory leak or security problem using them. I've learnt Pascal before C and the whole…

Brian Kernighan on "Why Pascal is not my Favorite Programming Language" (https://www.lysator.liu.se/c/bwk-on-pascal.html) [1981].

Turbo Pascal wasn't released until 1983, if the wiki is to be believed.

Re: Git's list of banned C functions

#595

Post by mcguire »

ineedasername wrote: post #479
MikeTheGreat wrote: post #463

Earlier quoted context omitted.

Minor detail: lecturers don't get tenure. The job role of 'professor' may be able to get tenure (I think these roles usually do) but 'lecturer' really means 'full time temporary teacher, with a contract for a specified amount of time.

I occasionally adjunct. What students call me at the beginning of the semester is always awkward: Them: "Hello Professor" Me: "Technically I'm not a professor." Them: "Okay, we'll just call you Doctor." Me: "Yeah, about that... not a doctor either." Them: "So why are we paying you?" Me: "Technically, you're paying the school. And the school is paying me... very little" Them: "Answer the question" Me: "Because I know…

If they ever ask "What do we call you?" you should answer,

"God-Boss."

(Pace Steven Brust.)

Re: Git's list of banned C functions

#596

Post by mcguire »

MikeTheGreat wrote: post #463
kbenson wrote: post #438

Earlier quoted context omitted.

Not if they're tenured. Then you can assume they'll never move.

Minor detail: lecturers don't get tenure. The job role of 'professor' may be able to get tenure (I think these roles usually do) but 'lecturer' really means 'full time temporary teacher, with a contract for a specified amount of time.

A short guide to academic titles: https://maniagnosis.crsr.net/2016/02/a-short-guide-to-academ...

Re: Git's list of banned C functions

#597

Post by mcguire »

nanagojo wrote: post #331
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.

> one of the best paying industries in this time and age Medicine is still better paid and better paid universally. Silicon valley is really the outlier here, most of Europe and the world programmers don't get paid that much in comparison.

Medicine has other filtering systems.

Re: Git's list of banned C functions

#598

Post by rbanffy »

jstanley wrote: post #538
sellyme wrote: post #363

Earlier quoted context omitted.

> In fairness, the moment you realize ASCII strings are a tiny subset of what a string can be, you also understand why strings are actually very complicated. Oh absolutely, but it's a pretty reasonable expectation that any contemporary language should handle that complexity for you. The entire job of a language is to make the fundamental concepts easier to work with.

C very much does make the fundamental concepts easier to work with, it merely disagrees with you about exactly which concepts are fundamental :).

Sadly, strings are, at the same time, complicated enough to be left outside the fundamental concepts of a language, but far too useful to be left outside the fundamental concepts of a realistically viable language.

Re: Git's list of banned C functions

#599

Post by Tempest1981 »

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

Important to note that strcpy_s doesn't truncate, it aborts your app if it fails:

> "if the destination string size dest_size is too small, the invalid parameter handler is invoked"

> "The invalid parameter handler dispatch function calls the currently assigned invalid parameter handler. By default, the invalid parameter calls _invoke_watson, which causes the application to close and generate a mini-dump."

https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer...

Re: Git's list of banned C functions

#600

Post by [deleted] »

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.

[deleted]
Post reply on HN