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

631–639 of 639 posts

Re: Git's list of banned C functions

#631

Post by JoeAltmaier »

renox wrote: post #630
JoeAltmaier wrote: post #575

Earlier quoted context omitted.

So many potential pitfalls to string functions. But memcpy and friends can have pitfalls too. I was working on a RISC processor and somebody started using various std lib functions like memcpy from a linux tool chain. I got a bug report - it crashed on certain alignments. Made sense - this processor could only copy words on word alignment etc. So I wrote a test program for memcpy. Copy 0-128 bytes from a source buffe…

>why the hell isn't there an instruction in every processor to efficiently copy from arbitrary source to arbitrary destination with maximum bus efficiency? Uh, you're not an hardware designer and it shows.. What if there's a page fault during the copy, you handle it in the CPU? That said, have a look at RISC-V vectors instruction (not yet stable AFAIK) and ARM's SVE2: both should allow very efficient memcpy(among oth…

Do they manage alignment? Say a source string starting at offset 3 inside a dword, to a destination at offset 1? That's the issue. Not just block copy of align register-sized memory.

Page fault is irrelevant. It already can happen in block copy instructions.

Re: Git's list of banned C functions

#632

Post by renox »

JoeAltmaier wrote: post #631
renox wrote: post #630

Earlier quoted context omitted.

>why the hell isn't there an instruction in every processor to efficiently copy from arbitrary source to arbitrary destination with maximum bus efficiency? Uh, you're not an hardware designer and it shows.. What if there's a page fault during the copy, you handle it in the CPU? That said, have a look at RISC-V vectors instruction (not yet stable AFAIK) and ARM's SVE2: both should allow very efficient memcpy(among oth…

Do they manage alignment? Say a source string starting at offset 3 inside a dword, to a destination at offset 1? That's the issue. Not just block copy of align register-sized memory. Page fault is irrelevant. It already can happen in block copy instructions.

No, they don't provide alignment but they provide a way to write code once whatever the size of the implementation's vector registers.

As for block copy instruction AFAIK there's no such things in RISC-V for example.

Re: Git's list of banned C functions

#633

Post by kelnos »

kaba0 wrote: post #509
kelnos wrote: post #410

Earlier quoted context omitted.

Because most projects involve interfacing with other third-party libraries that will undoubtedly not know about this other third-party library that implements a nice string.

It can contain a to_cstring() function and problem solved. If it uses a struct with length of string and pointer to a c-style string, even the conversion can be elided (at the price of some inflexibility/unnecessary copying while in use)

That would mean you lose the ability to do all sorts of optimizations and memory sharing. Or at least, you can do them, but then the c_string() function requires copying the data. And that also means that it's a one-way thing: you can't use the copy on something that wants to modify the string, and expect your FancyString instance to reflect the modification.

Re: Git's list of banned C functions

#634

Post by JoeAltmaier »

renox wrote: post #632
JoeAltmaier wrote: post #631

Earlier quoted context omitted.

Do they manage alignment? Say a source string starting at offset 3 inside a dword, to a destination at offset 1? That's the issue. Not just block copy of align register-sized memory. Page fault is irrelevant. It already can happen in block copy instructions.

No, they don't provide alignment but they provide a way to write code once whatever the size of the implementation's vector registers. As for block copy instruction AFAIK there's no such things in RISC-V for example.

So, no, they don't have anything like an arbitrary block copy that adjusts for alignment. Not surprising; nobody does. So we struggle in software, and have libraries with 11 bugs etc.

Re: Git's list of banned C functions

#635

Post by wbl »

int_19h wrote: post #542
wbl wrote: post #475

Earlier quoted context omitted.

In Java you do the exact same reallocation dance as append does behind the scenes when using arrays.

Java standard library does that, not you directly. The issue here is not performance, but rather ergonomics. For example, in Go, you can forget to assign the result of append to the variable, and it'll even work most of the time (because there was still some unused capacity in the array, so there was no need for reallocation).

Which method? Note im talking about the language level array, not ArrayList. Also this was years ago.

Re: Git's list of banned C functions

#636

Post by int_19h »

wbl wrote: post #635
int_19h wrote: post #542

Earlier quoted context omitted.

Java standard library does that, not you directly. The issue here is not performance, but rather ergonomics. For example, in Go, you can forget to assign the result of append to the variable, and it'll even work most of the time (because there was still some unused capacity in the array, so there was no need for reallocation).

Which method? Note im talking about the language level array, not ArrayList. Also this was years ago.

Java arrays don't have add() at all - they're fixed-size once allocated.

ArrayList etc do have add(), and they implement it by re-allocating the backing array once capacity is exceeded.

In practice, you'd use the ArrayList anyway. I don't think it's worthwhile comparing Go and Java "language-only", because the standard library is as much a part of the language definition as the fundamental syntax; indeed, what goes where is largely arbitrary. E.g. maps in Go are fundamental, but the primary reason is that they couldn't be implemented as a library in Go with proper type safety, due to the lack of generics.

Re: Git's list of banned C functions

#637

Post by account42 »

kazinator wrote: post #590
account42 wrote: post #553

Earlier quoted context omitted.

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 contex…

The threading aspect is one thing yes, but I think programmers forgetting or never realizing that these functions will magically behave differently for some of their users is a bigger problem.

I don't think having to pass a locale arguments would be that big of a problem - you could always have wrapper functions for the C locale, although they should be implemented directly for performance.

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

Yes, that would be ideal.

Re: Git's list of banned C functions

#638

Post by PoignardAzur »

mombul wrote: post #322
orwin wrote: post #184

Earlier quoted context omitted.

In my school, we had two days to understand the basics of text editors, git (add, commit, rebase, reset, push) and basic bash functions (ls, cd, cp, mv, diff and patch, find, grep...) + pipes, then a day to understand how while, if/else and function calls work, then a day to understand how pointer work, then a day to understand how malloc(), free() and string works (we had to remake strlen, strcpy, and protect them).…

Let's face it, the Moulinette was the hardest part.

No, the hardest part is not punching the asteks in the face when you ask them for help on a problem that has stumped you for two hours, they take one look at your code and they go "C'est pas à la norme!" AND THEY WON'T EVEN TELL YOU WHERE.

Re: Git's list of banned C functions

#639

Post by nostrebored »

lelanthran wrote: post #481
nostrebored wrote: post #469

Earlier quoted context omitted.

Medicine has been more poorly paid than FAANG software engineering in the last two places I've lived (South Africa, Australia)

> Medicine has been more poorly paid than FAANG software engineering in the last two places I've lived (South Africa, Australia) Interesting. I'm in South Africa, right now. The largest offer for a senior C# dev *right now* on www.pnet.co.za is R960k/a. Twelve years ago, the GP that I was dating, who worked in a *state hospital* (i.e. not making as much as she could have in private practice) was making more than that…

Happy to refer you to AWS! I was making over 1m rand (TC) as a mid level non dev position. I had friends in development making above the number you're talking.
Post reply on HN