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

601–610 of 639 posts

Re: Git's list of banned C functions

#601

Post by IgorPartola »

kaba0 wrote: post #589
IgorPartola wrote: post #562

Earlier quoted context omitted.

Benchmarks or it didn’t happen. The last OS project I saw was written in Rust and was twice as slow as Linux. It also required that all your software be written in Rust. This is why we keep seeing the “X is faster than C” articles: if you use the standard C library in a sort of not great way (sscanf) vs a more intelligent version of the code in another language you will get faster than C results. But on the whole doi…

I’m sorry but compare apples to oranges. A serious OS project is a tremendous multi-decade project, it has not much to do with the implementation language.

With the recent push from Rust community to implement OS kernels in Rust I think it is apt.

Re: Git's list of banned C functions

#602

Post by munchbunny »

tdeck wrote: post #393
m463 wrote: post #345

Earlier quoted context omitted.

I think 30-40 years ago it was perfectly appropriate to null-terminate strings. Every byte actually counted. I remember thinking about setting the high bit to denote the end of string to save space. Nowadays the binary for "hello world" might be as big as a whole operating system of the past. (though honestly I can't recall the size of the OS on a boot floppy, but the original floppies were 160k)

Just a surreal reminder that 30 years ago was 1991. By that time it already didn't make sense to null terminate strings (except perhaps on embedded platforms).

To be fair, in 1991, 1mb of RAM was a substantial amount for a PC, so a single word per string instead of a byte per string could still add up quickly.

Re: Git's list of banned C functions

#603

Post by CRConrad »

mytec wrote: post #366
lordgroff wrote: post #216

Earlier quoted context omitted.

Oh Pascal, why couldn't we have had you instead.

"Oh Pascal" reminded me of a book titled, "Oh! Pascal!" by Doug Cooper. I used it to learn Pascal.

Best programming book I ever read. His later "Condensed Pascal" isn't quite as good -- a little too, well, condensed. Too bad that's the only one I could find to buy after having had to return Oh, Pascal to the city library.

(OK, it's hard to compare; Code Complete and other much later stuff might be just as good. Too many decades between when I read them to say for sure.)

Re: Git's list of banned C functions

#604

Post by ajuc »

mcguire wrote: post #594
ajuc wrote: post #515

Earlier quoted context omitted.

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.

I find it strange that he complained about Pascal's lack of dynamic arrays, when the Pascal solution is to use pointers (exactly what C does for all arrays and strings anyway).

Many of his other points are solved by Turbo Pascal and Delphi/Object Pascal.

But of course nowadays there are better languages for real world programming. It's just a shame that there's nothing as simple and elegant for teaching programming ().

() lisp is even more elegant, but it has a lot of gotchas and it's so far from mainstream that using it for teaching isn't a good idea IMHO

Re: Git's list of banned C functions

#605

Post by crimper »

maerF0x0 wrote: post #186
crimper wrote: post #140

Earlier quoted context omitted.

channel programming and the races caused by closing channels. channels seem nice and easy until they don’t. the whole var/:=/= assignment combined with the error handling style and the shorthand is another one

yeah the lack of determinism in selecting a channel can be tricky for causing bugs where order matters. Luckily in smaller cases you're likely to encounter them as flakey tests (eg 1/2 the time) select { case

thanks for this, i couldn’t articulate it so clearly. Another gotcha is responding to closed channels, it makes sense in the grand scheme of things but when the program grows it gets tricky

Re: Git's list of banned C functions

#606

Post by Sohcahtoa82 »

kazinator wrote: post #220
retrac wrote: post #166

Earlier quoted context omitted.

For reasons that were never clearly articulated, the prefix approach was considered odd, backwards, and to have numerous downsides, at least where I learned C. In hindsight, I can only cringe at that attitude. Strings as added in later Pascal, about 40 years ago now, were memory safe in a way that C strings still are not.

Pascal strings are not inherently memory safe: cat_pascal_strings(pascalstr *uninited_memory, pascalstr *left, pascalstr *right); how big is uninited_memory? Can left and right fit into it? You need to design language constructs around Pascal srings to make them actually safe. Such as, oh, make it impossible to have an uninitialized such object. The object has o know both its allocation size and the actual size of th…

> struct foo ptr = malloc(sizeof ptr); // should be sizeof ptr!!

This is why whenever I use sizeof, I pass a type, not a variable.

Re: Git's list of banned C functions

#607

Post by dahfizz »

kevincox wrote: post #554
johnnycerberus wrote: post #547

Earlier quoted context omitted.

I wouldn't say that Go is an alternative approach. I mean, what's the difference between Go and Java AOT with Graal? But Rust is truly an alternative to C/C++.

In many ways Go is the safer more productive language for C lovers. There are only a couple major differences between the two languages so I think that it is one of the easier places to convince C lovers to move to. I have met a number of strong C proponents and they all seem to be relatively OK with Go, especially compared to C++, Rust and Python. The major differences in my head are: - Garbage Collection - Interfac…

As a low-level programmer, I am not convinced. The Go runtime really confuses the use case.

If I needed a C alternative, rust gives me all (most of) the power of C, plus safety, without all the drawbacks of a heavy runtime.

If I am okay with paying the garbage collection tax, etc, then I would use scala or kotlin. If I'm using a higher level language, then I expect higher level features like exceptions, generics, reflection, etc.

I'm sure go is a great language with it's own usecases, but it's not a C replacement.

Re: Git's list of banned C functions

#608

Post by Sohcahtoa82 »

astrange wrote: post #368
Sohcahtoa82 wrote: post #338

Earlier quoted context omitted.

> I don't really get the correlation between household income and programming experience in high school. > Their parents can't afford a laptop? Holy crap, the amount of privilege shown off in just two sentences is absolutely astounding. This may come as a shock to you, but a very significant number of people don't have a couple hundred dollars to buy a low-end used laptop. 40% of Americans would struggle to come up w…

> 40% of Americans would struggle to come up with $400 for an emergency expense [0], let alone save $400 for a laptop. It actually doesn't say that, it says they don't have $400 in cash equivalents but may be able to produce it by selling "assets". So a person who keeps all their savings in CDs or investments also counts, although only for expenses you can't put on credit cards.

Do you think people living paycheck-to-paycheck, constantly having to decide which bill to pay and which to allow to collect a late fee, have investments or CDs?

Re: Git's list of banned C functions

#609

Post by kevincox »

dahfizz wrote: post #607
kevincox wrote: post #554

Earlier quoted context omitted.

In many ways Go is the safer more productive language for C lovers. There are only a couple major differences between the two languages so I think that it is one of the easier places to convince C lovers to move to. I have met a number of strong C proponents and they all seem to be relatively OK with Go, especially compared to C++, Rust and Python. The major differences in my head are: - Garbage Collection - Interfac…

As a low-level programmer, I am not convinced. The Go runtime really confuses the use case. If I needed a C alternative, rust gives me all (most of) the power of C, plus safety, without all the drawbacks of a heavy runtime. If I am okay with paying the garbage collection tax, etc, then I would use scala or kotlin. If I'm using a higher level language, then I expect higher level features like exceptions, generics, ref…

I didn't say it was a C replacement, I said it was approachable to C programmers.

Most of the C lovers that I have spoken with find that Rust is far too complicated with templates and lifetimes. Similar arguments can be provided for Scala and Kotlin with their more functional syntax.

Re: Git's list of banned C functions

#610

Post by WalterBright »

sn41 wrote: post #540
WalterBright wrote: post #533

Earlier quoted context omitted.

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?

The trouble stems from the C Standard being copyrighted. Hence, anyone writing online documentation is forced to rewrite and rephrase what the Standard says. The Standard is written in very precise language, and is vetted by the best and most persnickety C programmers.

But the various rewrites and rephrases? Nope. If you absolutely, positively want to get it right, refer to the C Standard.

printf is particularly troublesome. The interactions between argument types and the various formatting flags is not at all simple.

Other sources of error are the 0 handling of `n` functions, and behavior when a NaN is seen.

Post reply on HN