From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3467 Path: news.gmane.org!not-for-mail From: Matthew Fernandez Newsgroups: gmane.linux.lib.musl.general Subject: Use of size_t and ssize_t in mseek Date: Thu, 27 Jun 2013 13:52:01 +1000 Message-ID: <51CBB6E1.6080302@nicta.com.au> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372305151 11763 80.91.229.3 (27 Jun 2013 03:52:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 03:52:31 +0000 (UTC) To: Original-X-From: musl-return-3471-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 27 05:52:32 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Us3G4-00058F-Jg for gllmg-musl@plane.gmane.org; Thu, 27 Jun 2013 05:52:32 +0200 Original-Received: (qmail 22130 invoked by uid 550); 27 Jun 2013 03:52:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22122 invoked from network); 27 Jun 2013 03:52:31 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19976.001 X-TM-AS-Result: No--14.972400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Xref: news.gmane.org gmane.linux.lib.musl.general:3467 Archived-At: Hi all, My question refers to the latest git commit at time of writing, b17c75a4d539d7ec5b81cc7ce7ce6b065a87e7a6. My issue was encountered on ARM, but it applies to most 32-bit platforms. The function mseek() accesses a size_t variable, c->size, and casts this to a ssize_t. I know there aren't strong standards on what to expect from ssize_t, but the Musl C constants SIZE_MAX (=3D=3D UINT32_MAX) and SSIZE_MAX (=3D=3D LONG_MAX) seem to imply that you would be wise to assume ssize_t is signed and the same width as size_t. As a result, the cast I mentioned produces some unexpected results when operating on a file of size greater than SSIZE_MAX. In my case I had an in-memory file of size SIZE_MAX and was surprised to find I couldn't fseek this file. Is the code in mseek() correct? If so, I would recommend failing fmemopen() when the requested size is greater than SSIZE_MAX. OTOH perhaps I'm misunderstanding something more subtle here. If so, please correct me. Thanks, Matthew [It is perhaps worth noting that, yes, a UINT32_MAX-sized in-memory file on a 32-bit platform is a bit odd. In my case I don't know how big the file is until I've read its header. You could object that this is unwise, but either way I believe fmemopen/mseek should handle this case.] ________________________________ The information in this e-mail may be confidential and subject to legal pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments.