Imagine that this allocation is for a buffer that is supposed to take user input. If the size is too small, you could easily be exposed to the classic buffer-overflow style of attacks. (That is, users know it's possible, craft a scenario to induce it, then deliver payloads.) So, yes, it's an issue.
well the solution is to validate user input. user input should certainly be limited to 4gb, at least. a wrapper around an allocator is definitely not the solution.
If you're going to validate user input, you first need to get it into kernel space, which requires allocating memory for it.
User input is not limited to 4 GB. Users can provide whatever they want; that's the point. You have to code for malicious users who are pushing your system towards its edge cases, trying to find holes to break through.
> If you're going to validate user input, you first need to get it into kernel space, which requires allocating memory for it.
i don't buy this - if you are going to allocate space, you must know the size of the space you are allocating. which you can validate, and certainly does not require going into kernel space to do.
Oh come on, what do you think the purpose of reallocarray is? It's exactly to include that boilerplate for you so that you don't have write your own "validation" before every alloc.
Letting the user (try) use as much as he needs can be perfectly okay. Even if it weren't, it doesn't necessarily mean the program itself needs to impose some limit to check the inputs against. There are other means, e.g. rlimits (which are enabled by default on OpenBSD).
What reallocarray does is the bare minimum validation that shoud always be done. And in many cases that is enough, though not always.
