[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1372521678.8324.18.camel@eris.loria.fr>
Date: Sat, 29 Jun 2013 18:01:18 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
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.
> It's the intent in musl that objects larger than the max value of the
> signed type corresponding to size_t simply never exist, so they don't
> have to be considered.
>
> Matthew was only able to get such a large size_t by 'guessing' - his
> bootloader (he ported musl to run on non-Linux) gave him a pointer to
> an object of unknown size, and he passed SIZE_MAX to fmemopen to
> attempt to read it as a file. This usage (giving size larger than the
> actual size of an object) is of course undefined behavior and not
> supported, but it's conceivable that his boot loader could have given
> him a valid size larger than SIZE_MAX/2 due to the bootloader and musl
> disagreeing on whether such objects can exist.
>
> The reason I question just adding a check here is that he could just
> as easily have happened to pass this object to snprintf, strnlen,
> memchr, etc., so from a standpoint of consistency, it doesn't make
> sense to me to add a check in one place but not others (and some of
> the others can't even report errors).
>
> My leaning at this point is just to document well that objects larger
> than SIZE_MAX/2 are assumed not to exist. I've already fixed the last
> two ways (mmap and shmget) they could be created with musl, so it
> seems to me the only way they can arise now is when you've done
> something like what Matthew has done and ported musl to a different
> underlying system, in which case this issue is one of many issues that
> should be considered as part of the port.
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.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
