Yes, but an API does not have to permit memory areas that large, so can restrict itself to int, if it chooses. It isn't necessarily a good choice, but it isn't necessarily wrong either. Especially if int is properly defined (which, of course, it isn't in one of your examples). A simple example might be something that reads a name from a user. If the input is defined to be at most 1000 characters, then a length that can hold at minimum 32767 is sufficient, and performance considerations can be taken into account.
And yes, there are some odd needs for size_t at times. Like that in the x86 real mode "large" model size_t can be unsigned int or long, and ptrdiff_t must be long. [Personally, I've always been disappointed that the 386 and later 32 bit (and larger) OSes don't seem to support anything but "tiny" model.] Jan Hudec writes: > 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 Isn't that what I said? > 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 <[email protected]> > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users --David Garfield _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
