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

531–540 of 639 posts

Re: Git's list of banned C functions

#531

Post by toxik »

de6u99er wrote: post #441
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.

I am seeing Python becoming the go-to language for many academics because it's easy to hack something together that somehow works. Unfortunately most of those developers don't care much about efficiency and Python is out of the box inefficient compared to other high-level languages like Java [1] or C#. OO Java courses circulating in academia lack modern functional, and to be frank educational, concepts and must to be…

Python and Java fill very different niches in the ecosystem. You're not going to cobble something together quickly in Java, the language just isn't designed to do that. Python is the software equivalent of cardboard-and-hot-glue prototyping, which is fairly common in academia.

Re: Git's list of banned C functions

#532

Post by [deleted] »

blahedo wrote: post #445
kab_al_ashraf wrote: post #423

Earlier quoted context omitted.

> You can work yourself into some weird corners because of how permissive the language is, where in a (strongly) typed language, the complier just says no. Could you share an example?

Here's one my (intro programming, non-major) students have just been tripping over this week: if word == "this" or "that": ... Not an error, always runs. Very mysterious to a beginner. (Shared with C/C++) Another one: counter = "0" for thing in things: if matches(thing): counter += 1 The error is in the init, by someone who is overzealous with their quoting, but the error is reported, as a runtime error, on the attem…

[deleted]

Re: Git's list of banned C functions

#533

Post by WalterBright »

dotancohen wrote: post #520
WalterBright wrote: post #435

Earlier quoted context omitted.

Whenever I review C code, I first look at the string function uses. Almost always I'll find a bug. It's usually an off by one error dealing with the terminating 0. It's also always a tangled bit of code, and slow due to repeatedly running strlen. But strings in BASIC are so simple. They just work. I decided when designing D that it wouldn't be good unless string handling was as easy as in BASIC.

Hello Walter! All things considered, you are probably the best person to ask for tips on string handling in C. Would you might sharing the things that you look for, from the obvious to the subtle? I would love to see some rejected push requests if possible. If I were writing C under your direction, what would you drill into me? Thank you, it is an honour to address you here.

1. whenever you see strncpy(), there's a bug in the code. Nobody remembers if the `n` includes the terminating 0 or nor. I implemented it, and I never remember. I always have to look it up. Don't trust your memory on it. Same goes for all the `n` string functions.

2. be aware of all the C string functions that do strlen. Only do strlen once. Then use memcmp, memcpy, memchr.

3. assign strlen result to a const variable.

4. for performance, use a temporary array on the stack rather than malloc. Have it fail over to malloc if it isn't long enough. You'd be amazed how this speeds things up. Use a shorter array length for debug builds, so your tests are sure to trip the fail over.

5. remove all hard-coded string length maximums

6. make sure size_t is used for all string lengths

7. disassemble the string handling code you're proud of after it compiles. You'll learn a lot about how to write better string code that way

8. I've found subtle errors in online documentation of the string functions. Never use them. Use the C Standard. Especially for the `n` string functions.

9. If you're doing 32 bit code and dealing with user input, be wary of length overflows.

10. check again to ensure your created string is 0 terminated

11. check again to ensure adding the terminating 0 does not overflow the buffer

12. don't forget to check for a NULL pointer

13. ensure all variables are initialized before using them

14. minimize the lifetime of each variable

15. do not recycle variables - give each temporary its own name. Try to make these temporaries const, refactor if that'll enable it to be const.

16. watch out for `char` being either signed or unsigned

17. I structure loops so the condition is That's all off the top of my head. Hope it's useful for you!

Re: Git's list of banned C functions

#534

Post by ajuc »

KptMarchewa wrote: post #400
nanagojo wrote: post #331

Earlier quoted context omitted.

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

Software development is usually better paid in Poland than medicine. Medicine starts to pay good way later in life, and only in certain specialisations.

And that's ultimately why we had the most surplus deaths in 2020 in EU.

Re: Git's list of banned C functions

#535

Post by indymike »

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…

I learned C before Pascal and having to write so much code to deal with 255 character limits was kind of jarring.

Re: Git's list of banned C functions

#536

Post by HelloNurse »

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.

What you call "format a string" is actually "begin a perilous expedition into uncharted memory".

Re: Git's list of banned C functions

#537

Post by bregma »

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.

C is a well-stocked kitchen of a language.

Unfortunately, it is riddled with sharp knives that can cut you, open flames that can burn you, gas that can smother you, water than can drown you and food that can make you sick if you prepare it incorrectly.

Some react to this potential safety threat by banning the use of knives, stoves, sinks, and food from a kitchen.

Fortunately most attempts at safety just require having a microwave to prepare the frozen pizza or Uber Eats delivery.

Re: Git's list of banned C functions

#538

Post by jstanley »

sellyme wrote: post #363
rbanffy wrote: post #346

Earlier quoted context omitted.

> strings in C are actually hard, Strings in C are more like a lie. You get a pointer to a character and the hope there is a null somewhere before you hit a memory protection wall. Or a buffer for something completely unrelated to your string. And that's with ASCII, where a character fits inside a byte. Don't even think about UTF-8 or any other variable-length character representation. In fairness, the moment you rea…

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

Re: Git's list of banned C functions

#539

Post by bregma »

rvense wrote: post #513
thisrod wrote: post #482

Earlier quoted context omitted.

I teach first-years in Australia, where boys from private schools call me "sir". When I'm feeling mean, I tell them to drop and give me ten pushups.

> ten pushups I'm guessing you don't teach computer science

OK. 10 push_backs() then.

Re: Git's list of banned C functions

#540

Post by sn41 »

WalterBright wrote: post #533
dotancohen wrote: post #520

Earlier quoted context omitted.

Hello Walter! All things considered, you are probably the best person to ask for tips on string handling in C. Would you might sharing the things that you look for, from the obvious to the subtle? I would love to see some rejected push requests if possible. If I were writing C under your direction, what would you drill into me? Thank you, it is an honour to address you here.

1. whenever you see strncpy(), there's a bug in the code. Nobody remembers if the `n` includes the terminating 0 or nor. I implemented it, and I never remember. I always have to look it up. Don't trust your memory on it. Same goes for all the `n` string functions. 2. be aware of all the C string functions that do strlen. Only do strlen once. Then use memcmp, memcpy, memchr. 3. assign strlen result to a const variable…

Thank you for the great list. Could you give examples of 8. subtle errors in online documentation?
Post reply on HN