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

551–560 of 639 posts

Re: Git's list of banned C functions

#551

Post by ufo »

moonchild wrote: post #486
ufo wrote: post #397

Earlier quoted context omitted.

We wouldn't need to go all the way to dependent types, which would guarantee at compile-time that array accesses are safe. Even if all the bounds checking happened at run-time it would still be tremendously helpful.

Bounds checking can be done, and it doesn't need any special language features. Tcc does it, as do some of the sanitizers (present in gcc and clang).

Can you bounds check dynamically sized arrays? For example, a function that receives the size as a separate argument?

    double f(double *xs, int n){
        return xs[g()];
    }

Re: Git's list of banned C functions

#552

Post by account42 »

akira2501 wrote: post #470
brmgb wrote: post #289

Earlier quoted context omitted.

The issue is pretending that C even has strings as a semantic concept. It just doesn't. C has sugar to obtain a contiguous block of memory storing a set number of bytes and to initialize them with values you can understand as the string you want. Then you are passing a memory address around and hoping the magic value byte is where it should be. C is semantically so poor, I find it hard to understand why people use it…

> but at least you can find a good subset of it. It's a constantly shifting subset, though. Moving slowly is a feature of C for some.

You can pick a subset of C++ now and it will not be worse in the future. There may be better ways to do things added but that seems a weird thing to complain about and you can just ignore it if you want.

Re: Git's list of banned C functions

#553

Post by account42 »

kazinator wrote: post #227
munchbunny wrote: post #180

Earlier quoted context omitted.

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

I agreee with you but it would be much better if every locale-dependent function had an argument for an explicit locale object.

Re: Git's list of banned C functions

#554

Post by kevincox »

johnnycerberus wrote: post #547
cesaref wrote: post #523

Earlier quoted context omitted.

I think the key is to understand the historical context of C, what it was competing with, and what concerns people writing C had. Compared to the alternative (straight assembler) at the time as a systems programming language, C is a massive step up. Also, the UNIX way was independent processes, so the APIs did not need to be thread safe, as there was no threading in the target architectures. Now given the massive amo…

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

- Interfaces

There are some other more minor things like defer and the built-in generic types but many C programmers already had macros to implement similar things.

So sure, Go doesn't solve all of the problem spaces that C does. But if you are in a problem space where you don't need see (or another low-level systems language) Go may be a middle ground to move C programmers to.

Re: Git's list of banned C functions

#555

Post by dotancohen »

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 Walter! I will be sure to internalize this. There are some terrific tips in here, such as using shorter array lengths for debug build and avoiding Thank you, have a great weekend!

Re: Git's list of banned C functions

#556

Post by enriquto »

ajuc wrote: post #550
enriquto wrote: post #514

Earlier quoted context omitted.

I don't understand your concern. How is teaching programming in school discriminatory? Would it be better to not teach programming at all?

Depends how you teach it. Imagine teachers at primary schools started teaching English by analyzing Shakespeare. Or imagine math was taught by giving kids all the axioms and requiring them to derive the other rules needed to solve tasks as needed :) Kids from well off families would be ok - it would just be considered another random thing you have to teach your kids to help them make it. But other kids would suffer a…

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 the best things that they learn in school are precisely those that I'm unable to teach them. For a start: mastery of the language, since I'm not a native speaker of the place where we live. I would be frankly enraged if the school lowered the level of language exigence to accommodate for the needs of my kids who do not speak it at home!

Re: Git's list of banned C functions

#557

Post by scoutt »

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…

Any runtime security measure produces overhead (array bounds checking, dynamically checked borrow rules like Rust RefCell, etc.), at least in computational cycles. There is no magic formula.

Calculating mandelbrot fractals to measure speed might be a nice exercise in which Rust or Zig can compete with C. But in a real software implementation, when you need to open a file you still have to call the OS function fopen(). Whatever thing File::open (Rust) is doing before calling fopen() is overhead.

How can you avoid that overhead? Write in C (at your own risk).

Re: Git's list of banned C functions

#558

Post by ajuc »

enriquto wrote: post #556
ajuc wrote: post #550

Earlier quoted context omitted.

Depends how you teach it. Imagine teachers at primary schools started teaching English by analyzing Shakespeare. Or imagine math was taught by giving kids all the axioms and requiring them to derive the other rules needed to solve tasks as needed :) Kids from well off families would be ok - it would just be considered another random thing you have to teach your kids to help them make it. But other kids would suffer a…

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 the start and going for 20% makes no sense.

You should expect people taking math at university to be able to solve linear equations and explaining it is a waste of time but you shouldn't expect kids in primary school to be able to do the same and it is your responsibility to prepare them in case they want to pursue academic career.

If public schools teach linear equations it's ok to assume that knowledge at university.

If they don't - it's not.

It should be the same with teaching programming and anything else is just funding rich people kids education by everybody's taxes.

The whole point of common public low-level education is to maximize the number of people participating in the economy. It's much better if everybody can read and write. Whole industries are impossible without this. And so is democracy.

It's the same with basic programming and math literacy. It benefits the whole society if vast majority of people have it.

If you "weed out" 60% or 80% of population just because they happen to be born in the wrong environment or went to the wrong school - you lose massive amounts of money and economic/scientific potential. Then you have to import these people from countries which don't fuck their own citizens in such a way.

Re: Git's list of banned C functions

#559

Post by aasasd »

johnnycerberus wrote: post #547
cesaref wrote: post #523

Earlier quoted context omitted.

I think the key is to understand the historical context of C, what it was competing with, and what concerns people writing C had. Compared to the alternative (straight assembler) at the time as a systems programming language, C is a massive step up. Also, the UNIX way was independent processes, so the APIs did not need to be thread safe, as there was no threading in the target architectures. Now given the massive amo…

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

> what's the difference between Go and Java AOT with Graal?

The thing that C/Go authors brought in straight from the seventies: utter garbage naming of identifiers.

But then again, the name of the language itself should be warning enough.

Post reply on HN