On Sep 13, 2015, at 1:29 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>>
>> (BTW, gsize is the spawn of Satan; it should never be used except when
>> you're dealing with GLib. It *should* have just been another name for
>> size_t, but it's 32 bits on 64-bit Windows, which means it's narrower
>> than size_t, which causes us some pain with g_snprintf().)
>
> Today I learned.
Yeah, gsize and gssize are huge botches in GLib.
gsize isn't strictly necessary, given that C's had size_t since at least C90 (probably C89, but I no longer have a copy of C89).
ssize_t is a POSIXism, required by system calls that take a size_t as a byte count and return the bytes transferred or -1 on error. Traditional UNIX used int for both, but the POSIX folks decided to use size_t for byte count arguments. size_t is unsigned, and 0 is, at least for read operations, unavailable as an error indication, as it means "end of data stream", they added a signed version of size_t for return values. Windows' _read() etc. still use int for byte counts and return values.
So *maybe* gssize is useful, but they really should have made them both 64-bit on 64-bit Windows.
