|
|
|
|
|
|
by apjana
2254 days ago
|
|
|
> glibc, for example > The standard library's function will be vectorized regardless of how your compiler was feeling that day We talked glibc. I mentioned there are libraries which do not do _any_ optimization other than a byte by byte copy. > I'm still not seeing why you can't replace the code between lines 881 and 902 Because you are considering only glibc. And yes, we can do a lot of things. But the function and copying buffers are not the top priority for us ATM. I shared it as an example in the context of the current topic. Not all code is supposed to match your preferences. > char * to a ulong * Both the source and destination are guarded by length and alignment requirement checks. |
|
|
Yikes, sorry if I came off as trying to force my opinion on your project. I'm just trying to understand the rationale behind the choices you made, since I've (clearly) never seen anything like it. (If I was genuinely interested in trying to modify your project to my desires, I hope you can believe I'd be kind enough to dig through the project to see if I could figure this out myself, then send a patch with rationale for you to decide whether you wanted it or not, rather than yell at you on Hacker News to fix it.) But to your points:
> We talked glibc. I mentioned there are libraries which do not do _any_ optimization other than a byte by byte copy.
I haven't actually seen one for quite a while–most of the libcs that I'm familiar with (glibc, macOS's libc, musl, libroot, the various BSD libcs, Bionic) have some sort of vectorized code. I'm curious if the project can run on some obscure system that I'm not considering ;)
> Both the source and destination guarded by length and alignment requirement checks.
Perhaps we have a misunderstanding here: I'm saying it's undefined by the C standard, as the pointer cast is a strict aliasing violation regardless of the checks. It will generally compile correctly as char * can alias any type, so the compiler will probably be unable to find the undefined behavior, but it's technically illegal. (I would assume this is one of the many reasons most libcs implement their string routines in assembly.)