From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14086 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [patch] return value of ulimit(UL_GETFSIZE) in X32 architecture Date: Thu, 25 Apr 2019 10:32:28 -0400 Message-ID: <20190425143228.GQ23599@brightrain.aerifal.cx> References: <869863DB5440B44FB22173F42FC3F3CE01CA3FC6@dggemm513-mbx.china.huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="191916"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14102-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 25 16:32:45 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hJfQa-000no9-Bc for gllmg-musl@m.gmane.org; Thu, 25 Apr 2019 16:32:44 +0200 Original-Received: (qmail 1557 invoked by uid 550); 25 Apr 2019 14:32:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1531 invoked from network); 25 Apr 2019 14:32:41 -0000 Content-Disposition: inline In-Reply-To: <869863DB5440B44FB22173F42FC3F3CE01CA3FC6@dggemm513-mbx.china.huawei.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14086 Archived-At: On Thu, Apr 25, 2019 at 01:44:24PM +0000, liucheng (G) wrote: > Dear ALL, > > Return value of ulimit(UL_GETFSIZE) in X32 architecture seems to be wrong. Is this x32-specific? Unless I'm mistaken this is always the case when long is 32-bit. POSIX notes in APPLICATION USAGE: "Since the ulimit() function uses type long rather than rlim_t, this function is not sufficient for file sizes on many current systems. Applications should use the getrlimit() or setrlimit() functions instead of the obsolescent ulimit() function." http://pubs.opengroup.org/onlinepubs/9699919799/functions/ulimit.html and marks the function obsolescent, without actually specifying what it should return in this case. A bug should probably be opened for clarification on that, but applications definitely should not be using the ulimit function. > Here is the implementation of ulimit function in MUSL 1.1.22: > #include > #include > #include > > long ulimit(int cmd, ...) > { > struct rlimit rl; > getrlimit(RLIMIT_FSIZE, &rl); > if (cmd == UL_SETFSIZE) { > long val; > va_list ap; > va_start(ap, cmd); > val = va_arg(ap, long); > va_end(ap); > rl.rlim_cur = 512ULL * val; > if (setrlimit(RLIMIT_FSIZE, &rl)) return -1; > } > return rl.rlim_cur / 512; > } > > Make it simple in case of "cmd = UL_GETFSIZE", ulimit function becomes to be: > long ulimit(int cmd, ...) > { > struct rlimit rl; > getrlimit(RLIMIT_FSIZE, &rl); > return rl.rlim_cur / 512; > } > > rl.rlim in ulimit function is the type of long long(8 Byte), however the return value in X32 architecture is the type of long(4 Byte). > So in that case, rl.rlim_cur / 512 would be larger than 0x7fffffff and ulimit function returns -1. > > > I also tried an experiment to improve my opinion as follows. > > [benchmark] > $ cat ulimit_test.c > #include > #include > > int main() > { > printf("ret:%d\n", ulimit(UL_GETFSIZE)); > > return 0; > } > > [testcase] > Environment: Linux 4.4.171 #1 SMP Thu Apr 25 00:39:22 UTC 2019 armv7l GNU/Linux > > $ /tmp # ulimit -f > unlimited > $ /tmp # ./ulimit_test > ret:-1 > $ /tmp # cp musl/libc.so /usr/lib/ // copy a new MUSL libc.so with my [patch] > $ /tmp # ./ulimit_test > ret:2147483647 // 0x7fffffff > > [patch] > --- > diff --git a/src/legacy/ulimit.c b/src/legacy/ulimit.c > index 1f59e8e..d1620e6 100644 > --- a/src/legacy/ulimit.c > +++ b/src/legacy/ulimit.c > @@ -1,6 +1,7 @@ > #include > #include > #include > +#include > long ulimit(int cmd, ...) > { > @@ -15,5 +16,5 @@ long ulimit(int cmd, ...) > rl.rlim_cur = 512ULL * val; > if (setrlimit(RLIMIT_FSIZE, &rl)) return -1; > } > - return rl.rlim_cur / 512; > + return rl.rlim_cur == RLIM_INFINITY ? LONG_MAX : rl.rlim_cur / 512; > } > --- The value LONG_MAX isn't correct either, since you can obviously create files larger than LONG_MAX. The "morally" correct behavior is probably returning -1 with an implementation-defined (unless/until POSIX standardizes it) of EOVERFLOW, the error used for similar interfaces (e.g. ftell) when a file size does not fit in long. Oddly, there's also no specification for what it should return when the limit actually is infinite. Rich