From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
Date: Sat, 29 Jun 2013 00:13:16 -0400 [thread overview]
Message-ID: <20130629041316.GG29800@brightrain.aerifal.cx> (raw)
In-Reply-To: <51CCED3F.3080303@nicta.com.au>
On Fri, Jun 28, 2013 at 11:56:15AM +1000, Matthew Fernandez wrote:
> >>>Alternatively, I could adjust the arithmetic to just avoid working
> >>>with signed values, and perhaps make it more obvious what it's doing
> >>>in the process.
> >>
> >>I would also be happy with this solution. The code in mseek could
> >>definitely be clearer. Not that I don't enjoy switch statements written
> >>as offsets into stack structs and reverse jumps ;)
> >
> >Yes, I think this is probably the best solution, even if it makes the
> >function a few bytes larger. The code should be more clear.
>
> Thanks, Rich. I appreciate you taking the time to consider this issue.
> Apologies that it seems to have steamrolled into all the ways of
> constructing invalid objects and possibly bored everyone else on this
> list :)
Looking at the code to "fix" it now, I ran into a problem. :-)
If size_t is 64-bit, there is fundamentally no way a memory buffer (or
disk file) larger than SSIZE_MAX can be accessed, since off_t cannot
store the position in the file. I noticed this as soon as I went to
write:
case SEEK_SET:
if (off < 0 || off > c->size) goto fail;
I could still salvage the 32-bit case by simply leaving the code alone
except for changing base to off_t, but I'm starting to remember why I
thought it was bogus to even consider allowing object sizes greater
than the signed size max...
Not sure what the best way to proceed is.
Rich
next prev parent reply other threads:[~2013-06-29 4:13 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-27 3:52 Matthew Fernandez
2013-06-27 4:10 ` Rich Felker
2013-06-27 4:16 ` Matthew Fernandez
2013-06-27 4:23 ` Rich Felker
2013-06-27 4:31 ` Matthew Fernandez
2013-06-27 15:34 ` Rich Felker
2013-06-28 0:49 ` Matthew Fernandez
2013-06-28 1:22 ` Rich Felker
2013-06-28 1:34 ` Matthew Fernandez
2013-06-28 1:48 ` Rich Felker
2013-06-28 1:56 ` Matthew Fernandez
2013-06-29 4:13 ` Rich Felker [this message]
2013-06-29 13:38 ` Matthew Fernandez
2013-06-29 14:17 ` Rich Felker
2013-06-29 14:56 ` Jens Gustedt
2013-06-29 15:48 ` Rich Felker
2013-06-29 16:01 ` Jens Gustedt
2013-06-29 16:13 ` Rich Felker
2013-06-29 16:39 ` Jens Gustedt
2013-07-04 1:28 ` Rich Felker
2013-07-04 6:11 ` Jens Gustedt
2013-07-04 6:37 ` Rich Felker
2013-07-04 7:11 ` Jens Gustedt
2013-07-04 8:12 ` Rich Felker
2013-07-04 8:45 ` Jens Gustedt
2013-07-04 15:24 ` Rich Felker
2013-07-04 11:10 ` Szabolcs Nagy
2013-07-04 11:58 ` Jens Gustedt
2013-07-04 15:26 ` Rich Felker
2013-06-27 10:35 ` Szabolcs Nagy
2013-06-27 15:05 ` Rich Felker
2013-06-27 16:47 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130629041316.GG29800@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).