Date: Sat, 29 Jun 2013 12:13:38 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Use of size_t and ssize_t in mseek On Sat, Jun 29, 2013 at 06:01:18PM +0200, Jens Gustedt wrote: > Am Samstag, den 29.06.2013, 11:48 -0400 schrieb Rich Felker: > > The type in the interface can't be changed. It's required by POSIX > > (and for many interfaces, required by C). However if rsize_t were > > defined as size_t and RSIZE_MAX were SIZE_MAX/2, it would at least > > partly convey the intent. > > it is so defined by C11. In K 3.3 we have: > > The type is rsize_t which is the type size_t. OK. > I basically understood all of this, I think. My point was that when > thinking about ways to handle the maximum size of objects, it would be > good to use the means that the C standard provides for such a > thing. "Implementing" Annex K partially by typedeffing size_t to > rsize_t and defining RSIZE_MAX to SIZE_MAX/2 would be a good point in > that direction, and clearly document the choice. I'm not sure how useful it would be to applications. These macros and types can't be exposed unless __STDC_WANT_LIB_EXT1__ is defined by the application, so in practice they won't be exposed. With that said, I'm not opposed to adding Annex K, but I think we should look into how invasive it would be, i.e. whether most/all interfaces can just be wrappers for the non-bounds-checking versions or whether major internal changes would be required to some existing interfaces. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.