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

561–570 of 639 posts

Re: Git's list of banned C functions

#561

Post by ClumsyPilot »

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…

When we talk about a language, we tend to mix together the language itself and it's ecosystem/runtime/tooling. For example C# can be compiled to produce single-megabyte executables, you could concievably use it without a GC, but that's very non-standard tooling with poor support. So practically speaking, C# can't do that for most people for most usecases, even if hypothetically the language could.

So currently the issue is you can't write baremetal stuff in Go, for example the linux kernel or Arduinos. You can't get rid of GC if you have realtime requirements.

GO is 'close enough' to C in many areas like writing server-side code and CLI tools - it's GC pauses are short, even though C could produce an executables in a few KB, rather than an MB, that has no practical relevance in those areas.

Re: Git's list of banned C functions

#562

Post by IgorPartola »

paavohtl wrote: post #484
IgorPartola wrote: post #295

Earlier quoted context omitted.

Two ways to look at it. If I told you that your computer or phone could run the same OS and all the same programs but at 1/10th of the speed so that certain classes of bugs could be eliminated, would you make that switch right here and now? I don’t mean theoretically I mean the device you are looking at right now. If not, would you do that in a year? On the other hand, Moore’s law and all that. Computers will get fas…

You're ignoring the fact computer science has advanced since the 1970s when C was created. C is not full of footguns because that's the only way to build a fast language, it's unsafe because it's old and full of legacy baggage. Modern systems languages (primarily Rust, and to a lesser extent Zig) are on par with C in terms of performance, yet eliminates entire classes of potential safety bugs. Rewriting of course has…

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 doing less work is always faster. Not doing bounds checking on an array will always be faster than doing bounds checking. How could it not be? No amount of computer science can make bounds checking take negative time.

I am not saying C is magically faster. I am saying that by letting you not do critical safety checks it will be faster. Rust has a similar capability for some things but if your goal is to write unsafe Rust for the sake of performance, then is it worth the switch?

Re: Git's list of banned C functions

#563

Post by enriquto »

ajuc wrote: post #558
enriquto wrote: post #556

Earlier quoted context omitted.

I understand what you mean. This has nothing to do with programming, it's a general (and difficult!) concern regarding everything that is taught at schools. By that same argument, schools should not teach anything that is not widely known by 100% of the parents of each kid. Otherwise, it would be discrimination to those kids whose parents cannot help. I disagree very strongly with this principle. I have two kids, and…

> By that same argument, schools should not teach anything that is not widely known by 100% of the parents of each kid. Otherwise, it would be discrimination to those kids whose parents cannot help. I disagree very strongly with this principle. Not at all what I mean. I mean schools (at least primary schools) should be designed for top 80% or 90% not for top 10% or 20%. You can never get to 100% but resigning from th…

I agree that public school should not leave any kids behind. I also want my taxes to be raised to fund a higher-level education for kids who may find it useful, even if it's only a small percentage of kids.

Re: Git's list of banned C functions

#564

Post by bunnythefifth »

10x-dev wrote: post #494
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.

Mr. Bright, I just want to thank you for creating D. It is by far my favorite language, because it is filled with elegant solutions to hard language problems. As a perfectionist, there are very few things I would change about it. People rave about Rust these days, but I rave about D in return. Just wanted to say thanks (and that I bought a D hoodie).

Your words have just convinced me to try out D. Maybe some good will come out of it :)

Re: Git's list of banned C functions

#565

Post by kevincox »

ClumsyPilot wrote: post #561
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…

When we talk about a language, we tend to mix together the language itself and it's ecosystem/runtime/tooling. For example C# can be compiled to produce single-megabyte executables, you could concievably use it without a GC, but that's very non-standard tooling with poor support. So practically speaking, C# can't do that for most people for most usecases, even if hypothetically the language could. So currently the is…

I think you are agreeing with me. Go fails to solve some problems that C does, but feels fairly comfortable to C programmers. Therefore it works well for C programmers when solving problems that can be solved by Go.

Re: Git's list of banned C functions

#566

Post by cblconfederate »

kaba0 wrote: post #506
cblconfederate wrote: post #308

Earlier quoted context omitted.

thats probably because pointers are considered "hard" , too hard to exist in other languages. It's interesting that in the 80s, the standard library modeled C++ iterators with pointer semantics because they assumed everyone could do pointer arithmetic, but nowadays the concept is not mainstream at all.

I don’t think the reason for hiding pointers is because they are hard — it’s just that arbitrary pointer arithmetics are especially error prone and can be avoided in most codebases.

well hard to get right anyway. in any case newer generations of programmers are less likely to be familiar with the pattern

Re: Git's list of banned C functions

#567

Post by ajuc »

enriquto wrote: post #563
ajuc wrote: post #558

Earlier quoted context omitted.

> By that same argument, schools should not teach anything that is not widely known by 100% of the parents of each kid. Otherwise, it would be discrimination to those kids whose parents cannot help. I disagree very strongly with this principle. Not at all what I mean. I mean schools (at least primary schools) should be designed for top 80% or 90% not for top 10% or 20%. You can never get to 100% but resigning from th…

I agree that public school should not leave any kids behind. I also want my taxes to be raised to fund a higher-level education for kids who may find it useful, even if it's only a small percentage of kids.

Sure but that's only fair if the assumed skills at higher levels are attainable for an average person that went to a public school.

BTW "no child left behind" isn't practical, there are people who can't learn basic stuff no matter how hard you try. But "less than X% kids left behind" is for some low value of X.

Re: Git's list of banned C functions

#568

Post by aydwi »

IgorPartola wrote: post #562
paavohtl wrote: post #484

Earlier quoted context omitted.

You're ignoring the fact computer science has advanced since the 1970s when C was created. C is not full of footguns because that's the only way to build a fast language, it's unsafe because it's old and full of legacy baggage. Modern systems languages (primarily Rust, and to a lesser extent Zig) are on par with C in terms of performance, yet eliminates entire classes of potential safety bugs. Rewriting of course has…

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…

Reminds me of something I once read on Evan Martin's (creator of the Ninja build system) blog [1].

"Underspecifying and overspecifying.

Ninja executes commands in parallel, so it requires the user to provide enough information to get that correct. But at the other extreme, it also doesn't mandate that it has a complete picture of the build. You can see one discussion of this dynamic in this bug in particular (search for "evmar" to see my comments). You must often compromise between correctness and convenience or performance and you should be intentional when you choose a point along that continuum. I find some programmers are inflexible when considering this dynamic, where it's somehow obvious that one of those concerns dominates, but in my experience the interplay is pretty subtle; for example, a tool that trades off correctness for convenience might overall produce a more correct ecosystem than a more correct but less convenient alternative, if programmers end up avoiding the latter. (That could be one reason Haskell isn't more successful. Now that I work in programming languages I see this dynamic play out regularly.)"

[1] http://neugierig.org/software/blog/2020/05/ninja.html

Re: Git's list of banned C functions

#570

Post by synergy20 »

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…

Super insightful list.

What will be the alternative for strncpy/strncat? I thought they're a safer strcpy/strcat but now I need something to replace them.

I assume snprintf for sprintf, vsnprintf for vsprintf.

No idea what to do with gmtime/localtime/ctime/ctime_r/asctime/asctime_r, any alternatives for them too?

Post reply on HN