ByteBuffer uses UInt for Capacity, but Int internally

[helje5]

Separated out of #486, ByteBuffer-core.swift has this:

private static func allocateAndPrepareRawMemory(bytes: Capacity, allocator: Allocator) -> UnsafeMutableRawPointer {
  let bytes = Int(bytes) /* Note(hh): this can fail on 32-bit (Int32 vs UInt32 Capacity)) */

where Capacity is

typealias Capacity = UInt32

This can fail on 32-bit platforms where Int cannot hold any UInt32 value (e.g. 0xDEADBEEF). Apparently the Int is used because of:

let sysMalloc: @convention(c) (Int) -> UnsafeMutableRawPointer? = malloc

TBD: What should be used here. Maybe size_t? That would be better, but theoretically it would still break ByteBuffer on platforms wheresize_t is less than UInt32, e.g. Int32 sounds at least possible for size_t.
Presumably Int is also often used in Swift itself (e.g. the capacity of a UnsafeBufferPointer is probably an Int?)

[weissi]

ha, that's fun. We chose Int indeed as that's what Swift usually does and indeed UnsafeBufferPointer's count property is of type Int...

@lorentey / @airspeedswift / @moiseev what do you propose?

[lorentey]

I think the most pragmatic approach is to limit counts and sizes to values that fit in a signed integer. (>=2GiB buffers are probably unlikely to occur in practice on 32-bit platforms, anyway.)

[weissi]

I'm happy with saying that ByteBuffer supports 2GB on 32bit and 4GB on 64bit, @Lukasa & @normanmaurer ?

[helje5]

I think a current Raspi comes with 1gb and usually no swap. In other words: I agree, 2gb is enough for everybody.

[Lukasa]

No objection from me.

[weissi]

@helje5 I think we now all agree that 2GB is enough for 32bit so I'll close this, ok?

[helje5]

Sure, fine with me.