mallocBytes allows underflow

https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Foreign.Marshal.Alloc.html#mallocBytes

This function doesn't complain when passed a negative number. Instead you get something like

*** Exception: malloc: resource exhausted (out of memory)

Which is confusing, and probably not consistent across platforms.

This came up in https://github.com/tel/saltine/issues/42

Trac metadata

Trac field	Value
Version	8.0.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	libraries/base
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import core libraries labels

mallocBytes does a conversion from Int (signed) to CSize (unsigned). On 64bit Linux system Word and CSize have the same size so this function could use Word as argument, but I wonder if this is always the case.

In any case I think the argument should be an unsigned type (Word, CSize, or something else).

I agree, changing the argument type to Word is probably the most semantically sensible approach. It has the nice effect of shifting the responsibility of underflow detection to the caller.

I think the ecosystem in general could benefit from a wide-ranging examination of whether “Int” is actually appropriate (indexing, lengths, etc.).

Would someone care to offer a patch?

This would probably need to go through libraries committee review process, right?

Indeed it does.

Trac metadata

Trac field	Value
CC	osa1 → core-libraries-committee@haskell.org, osa1

Not to gum up the works, but is there a comprehensive list of Int-consuming functions like mallocBytes that should have an explicit overflow check? If so, perhaps one could just send that list to the libraries mailing list, and see if folks are OK with changing all of their Int arguments to Word.

I'm all in favor of using Word instead of Int but mallocBytes is part of Haskell2010 (Foreign.Marshal.Alloc) so it's going to be painful to get the change accepted.

If we ever do it, we can fix most other uses of Int in the report: e.g., in Data.List, in Data.Bits, etc. We could also fix GHC's primitives (unsafeShiftRL#, etc.).

Switching to Word is more likely to hide mistakes as oversized allocations due to wrap-around. I'd prefer to keep the computations at the Int type and have the check implemented once in mallocBytes than to have to see that check duplicated out to every caller of mallocBytes.

added error messages label

added Pnormal label