NagyDonat wrote: > > [...] **while negative-sized allocations are not currently covered but > > would be easy to handle.)** > > I didn't read the discussion but I'm not sure how to interpret this > highlighted sentence.
It's just a dumb mistake, I just forgot that the parameter of `malloc` is unsigned. > [...] What I advocated for a long time to consider the malloc parameter as-if > it was `rsize_t` (introduced by C11 Annex K > [N1570](https://www.iso-9899.info/n1570.html), which is basically `size_t` > except that the most significant bit is never supposed to be set. Like > passing a negative value to such API, it would go through a signed->unsigned > conversion, thus set the MSB; thus its an effective way of detecting > "negative" arguments)) Is it similar to what you have in mind? I like this approach, and I would support activating it in our analysis – there is no non-buggy applications of these oversized allocations. In fact, we already have a check where we report an error if the allocation size is tainted and it can be larger than `SIZE_MAX / 4`. We could extend that (or something like it) for situations where the allocation size is non-tainted but definitely too large. https://github.com/llvm/llvm-project/pull/150028 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
