On Mon, Sep 26, 2011 at 12:44:08 -0400, David Garfield wrote:
> Using int instead of size_t A) unnaturally limits data length,
> possibly to 64K and B) doesn't well describe the data. Beyond that,
> it isn't necessarily a bug. The language needed size_t to provide a
> type guaranteed to be sufficient to hold any sizeof() result, but no
> API need use it.
Quite the oposite. size_t can, by definition, be used to represent size of
any object that may ever exist in memory on given platform. For static
arrays, the sizeof returns their total size in bytes, so size_t (being the
return type of sizeof) has to be large enough to hold that value. For dynamic
arrays malloc takes it's argument as size_t, so obviously size of block it
returns is representable by size_t.
Now I don't know any platform where size_t is smaller than int, but I know at
least two cases where size_t is larger than int:
- All 64-bit platforms have 32-bit int, but 64-bit size_t.
- x86 in 16-bit real mode had 16-bit int, but the "huge" memory model
allowed allocating blocks larger than 64K and thus had to have 32-bit
size_t.
--
Jan 'Bulb' Hudec <b...@ucw.cz>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
