and sizeof(hwrpb) is now 16 bytes, then you will be copying 12 bytes of data too many from the caller, potentially reading into memory it doesn't own. I would say that should be avoided.
The better solution I believe would be to only copy the minimum amount of bytes supported by caller & callee. So:
nbytes = MIN(nbytes, sizeof(hwrpb));
Which should ensure backwards and forwards compatibility, assuming the version info of hwrpb->size is respected then the fact that part of the hwrpb struct isn't initialized shouldn't matter.
Right, but the size of the buffer is given, it doesn't make sense to stomp over end of the callers buffer either, so you can't use pass in something longer than `nbytes` either.
If the buffer isn't large enough to hold *hwrpb, then it already fails. The original check was good, only needed to change the amount of bytes copied to sizeof(*hwrpb).
No, because if nbytes > sizeof(*hwrpb), your version causes the kernel to only write part of the buffer, and then when the app accesses fields at the end of the struct, it would read uninitialized data, which is very bad.
Recall that the API is intended to be used like this:
At first glance, it might seem unnecessary to pass the buffer size at all, because in theory the user and kernel should agree on what the sizeof(struct hwrbp) is. But the reason it is passed is because there are various reasons why the separately compiled kernel and user binaries might disagree (e.g., incorrect compiler flags, wrong header file being used, struct has changed between different versions, etc.), and it's useful to detect that. So you can make an argument that the most conservative check is:
if (nbytes != sizeof(\*hwrpb)) return -1;
After all, if the user and kernel disagree on the correct size of the struct, then something is wrong! But allowing nbytes < sizeof(*hwrpb) has the benefit that the kernel developers can add fields at the end of the struct without breaking backward compatibility with older applications.
I would agree with you if the kernel had some other mechanism to pass the size of the buffer that was actually filled to the client (like e.g. the read() syscall does) but the getsysinfo() API doesn't return that data, so the kernel must either fill the buffer entirely or return failure.*
> No, because if nbytes > sizeof(*hwrpb), your version causes the kernel to only write part of the buffer, and then when the app accesses fields at the end of the struct, it would read uninitialized data, which is very bad.
> I would agree with you if the kernel had some other mechanism to pass the size of the buffer that was actually filled to the client (like e.g. the read() syscall does) but the getsysinfo() API doesn't return that data, so the kernel must either fill the buffer entirely or return failure.
As you mention, this struct is versioned. Userspace can tell how much of the struct was filled by checking the size field (hwrpb->size).
> But allowing nbytes < sizeof(*hwrpb) has the benefit that the kernel developers can add fields at the end of the struct without breaking backward compatibility with older applications.
That's a related but separate issue. Backward compatibility can be handled by switching on nbytes or by copying fewer bytes with a carefully designed struct. It's not clear that backward compatibility was the original intention of this code, the original intention more seems to be sanitizing tainted input. This struct has not changed in at least 16 years.
The original less-than check was deemed incorrect, and was replaced entirely. For good or for ill, it seems the author deems it valid to pass in a value smaller than sizeof *hwrpb, and that many bytes will be dutifully copied. This might form part of some barebones API versioning mechanism.
Hacker News is not the best crowd for something like this. Everyone here most likely already has their own optimized workflow for something like this, including me.
This is probably best suited for digital creative types who use Windows and Mac and aren't comfortable with the terminal. Animators, illustrators, video editors, 3d artists, music producers, youtubers, streamers, etc.
It's not clear to me that that second group wants something like this. To be fair, from your marketing I have no idea what your software does and I doubt that group would either. I get that you're trying to communicate this is a "universal" file experience but what does that mean in concrete terms? Users shouldn't have to install your software to understand what it does. I also don't see them caring that this is open source or works on Linux.
At this stage I would totally refresh the marketing and optimize it for that second group. Work with a PR person or marketing expert that understands how to concretely and efficiently communicate the value of what you are building to that second group. I would also take down the source repos and discontinue the Linux version (or keep it private for now, until there is demand) to save your team effort at this super early stage.
The study did not show that Ivermectin killed SARS-CoV-2 viral particles. Prior to the pandemic, Ivermectin was known to act as an broad anti-viral. This is due to Ivermectin being a protease inhibitor, i.e. it blocks an enzyme from acting. It's important to note that this is the mechanism through which approved anti-virals for SARS-CoV-2, such as Paxlovid, operate.
There are also some studies indicating that it can shrink certain tumors. My assumption was that it just stirred up the immune system in general, un thevsame way that a flu shot can decrease the severity of a cold.
It would be nice if every comment was fully cited, but would probably be counter-productive since most people don’t have the time to find citations.
Until everyone’s knowledge is represented in some kind of knowledge graph, simply finding a citation “of that paper I read last year” can be a lot of work. So for now, it’s more effective to talk generally and cite a paper when it is relevant (when discussing methods etc).
