From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1647 invoked by alias); 24 Jul 2019 10:48:25 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 1594 invoked by uid 89); 24 Jul 2019 10:48:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=tracker, our X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jul 2019 10:48:19 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B28A0B2DC7; Wed, 24 Jul 2019 10:48:17 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-200.str.redhat.com [10.33.192.200]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0FBC160BEC; Wed, 24 Jul 2019 10:48:16 +0000 (UTC) From: Florian Weimer To: Yang Xu Cc: Subject: Re: question about prctl return value type References: <5D382C5F.6020806@cn.fujitsu.com> Date: Wed, 24 Jul 2019 10:48:00 -0000 In-Reply-To: <5D382C5F.6020806@cn.fujitsu.com> (Yang Xu's message of "Wed, 24 Jul 2019 18:01:03 +0800") Message-ID: <87pnlzn1xs.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00022.txt.bz2 * Yang Xu: > Since kernel syscall use long value for return, why we set int in > sys/prctl.h(glibc). as below: > > /include/sys/prctl.h > > 1 #ifndef _SYS_PRCTL_H > 2 #include_next > 3 > 4 # ifndef _ISOMAC > 5 > 6 extern int __prctl (int __option, ...); > 7 > 8 # endif /* !_ISOMAC */ > 9 #endif Note that the actual user-visible header is sysdeps/unix/sysv/linux/sys/prctl.h, but it has the same issue. > If we calling prctl(PR_SET_TIMERSLACK, ULONG_MAX) and then calling prctl(PR_GET_TIMERSLACK), the value > will be truncated into INT_MAX(or convered into unsinged,it is UINT_MAX) on 64bit machine. Or, this is a > glibc limitation for prctl interfaces? I think this is a glibc limitation/bug. The return type should probably be __register_t (a type that is currently woefully underused). We cannot simply change the return time because once applications are built against the new prototype, we need to ensure that they also use the new glibc. Would you please file a bug for this? is our bug tracker. Thanks, Florian