[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
