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

581–590 of 639 posts

Re: Git's list of banned C functions

#581

Post by schlupa »

cestith wrote: post #254
pix64 wrote: post #245

Earlier quoted context omitted.

strlcpy() isn't standard. You have to provide your own implementation if you want your code to be portable.

This is something git does. That's why they prefer it - it's available to git everywhere.

and

     *((char*)mempcpy(dst, src, min(len, dstsize-1))) = 0;
can be replace by

     ((char*)memcpy(dst, src, min(len, dstsize-1))[min(len, dstsize-1)] = 0;
if you don't have mempcpy

Re: Git's list of banned C functions

#583

Post by michaelt »

enriquto wrote: post #514
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.

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

paganel doesn't think it's discriminatory to teach programming. Rather, he thinks orwin describes a class that's too fast paced - a class that wouldn't teach much, and would mostly weed out kids who hadn't self-taught themselves before they reached college.

He fears while a professor might imagine they're weeding out people who lack 'dedication' or 'aptitude' they're actually weeding out people who didn't grow up with a PC at home.

Re: Git's list of banned C functions

#584

Post by JdeBP »

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.

I was hoping that someone would have already pointed out that this is not quite correct phraseology, as the qualifier "old ways to" has to be inserted: e.g. "old ways to get time in GMT". The "new" ways have been around for nigh on 30 years in some cases, and aren't really "new" now. I've been using localtime_r() for almost that long, for example. Coming from another language, don't be fooled into thinking that what you are looking at in these lists is the current state of the art for the language.

Re: Git's list of banned C functions

#585

Post by kaba0 »

unbalancedevh wrote: post #249
frob wrote: post #138

Earlier quoted context omitted.

As someone who learned C as their first language, strings in every single language after that have felt like cheating. "What? You mean I can type an arbitrary string and it works? I don't need to worry about terminators or the amount of memory I've allocated? You can concatenate two strings with +?!? What is this magic?"

It always makes me wonder if there's some hidden overhead that I'm absorbing. When I program in C I feel like I know a lot better what the generated instructions will be. Using higher-level languages for embedded programming where resources are tight makes me uncomfortable.

To be honest, with today’s compilers you can’t be all that sure about the generated code. They do some insane tricks under the hood to make naively written code perform good. As per a “famous” blog post, C is a high level language.

Re: Git's list of banned C functions

#586

Post by throw0101a »

munchbunny wrote: post #434
throw0101a wrote: post #428

Earlier quoted context omitted.

(Many of) The trade-offs were known to Richie et al ; writing in 1993: > None of BCPL, B, or C supports character data strongly in the language; each treats strings much like vectors of integers and supplements general rules by a few conventions. In both BCPL and B a string literal denotes the address of a static area initialized with the characters of the string, packed into cells. In BCPL, the first packed byte con…

Thanks for the reference! I personally don't think that the qualitative pros/cons of the chosen approach or alternatives that we're discussing today, 30-ish years later, would be all that new to the designers of C in 1993. The difference is that we've had 30-ish years to watch those decisions play out over millions of lines of code in software running at scales and levels of complexity that programmers in 1993 could…

> Also, software security was barely an issue in 1993. Today, it's a massive issue.

That was him reflecting on things in 1993, but the C team designed things in ~1970. That was basically the Stone or Iron Age of computing.

Re: Git's list of banned C functions

#587

Post by kaba0 »

1f60c wrote: post #329
UncleMeat wrote: post #280

Earlier quoted context omitted.

An old grad school connection of mine wrote a formal semantics for ES5 and couldn't explain what "with" did in words.

This is JavaScript, so there are probably tons of weird edge cases, but basically , within a with (expr) { … } block, everything defined on expr is put in scope: with (Math) with (console) log(PI) It reminds me a bit of Clojure's doto.

Or java’s static import

Re: Git's list of banned C functions

#588

Post by kaba0 »

scoutt wrote: post #557
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…

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

Compile time security measures have absolutely no runtime overhead. Also, I don’t see what you mean by File::open — there is a kernel call somewhere there. But if you are writing a new OS you are free to implement the fopen call as you wish - C has no advantage here.

Re: Git's list of banned C functions

#589

Post by kaba0 »

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…

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.

Re: Git's list of banned C functions

#590

Post by kazinator »

account42 wrote: post #553
kazinator wrote: post #227

Earlier quoted context omitted.

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

The problem is you'd have to pass an annoying extra argument (even if just a NULL) to numerous functions which have no alternative without that argument.

Technically it would be better, especially from a multi-threading point of view. The locale stuff was designed in the 1980's, before multi-threading was a mainstream technique.

Say you have a multi-threaded global server which has to localize something in the context of a session, to the locale of the user making the request.

Still, for thread support, you don't necessarily need a cluttering argument. The locale can be made into a thread-specific variable. In Lisp I would almost certainly prefer for the local to be a dynamic variable. (It would be pretty silly to be passing an argument to influence whether he decimal point is a comma, while the radix of integers is being controlled by *print-base*.)

What you want is for the locale stuff to be broken out into a complete separate library: a whole separate set of loc_* functions: loc_strtod, loc_printf, and so on.*

Post reply on HN