From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 504C9385481B; Thu, 29 Oct 2020 11:12:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 504C9385481B Received: by mail-wr1-x431.google.com with SMTP id k10so960539wrw.13; Thu, 29 Oct 2020 04:12:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nGF0VX0ft+3zZ98jIc8cmGnrE2OnEnOJbC/9MRqxrP4=; b=NzmXgAclPEmyokJzorxRcE9w8cE5PRPv82si38h5ahifJLq/u0VyKQIY6bB5pfLMbo Mme4Hmv7RKb4y57mgrSn1Wwo52ZWU3T6deW8MPDqP2P5d8OedmYU1pHKQkQVtRo1jK2+ EPMOvxGKBIZK8FmQQZXNLHibZfKHuedCMju0DxVveh20fBQsx6s4JQLriOwBsrwOd9xj 35PpqAtM3oP7ovhn5E3aZZttBNQaGnka4kMvtk9ibOnpJdcN3kUzWYsgyJewloFyWHnG qs97f5MLq6uv31rhkS78myQOB0S48/AzhNi31S/jVeWvjIdVkJ6cRTmBVSDIoT14mSgH nqrA== X-Gm-Message-State: AOAM531GOHac04YL1UlO0HkwgTCPjrykcx8YCAXDD+Gwwzfg9xv/3lyn sB7VdvV/KGMMLTGP0cFBhiI= X-Google-Smtp-Source: ABdhPJy8vmbwTsWJqDpQ47Q5ypSi+ODunBqjZ8Doblh3xsENbgc6V3uc7h6NXJzWBIFV3sVlMldDZA== X-Received: by 2002:adf:e486:: with SMTP id i6mr2228713wrm.397.1603969933495; Thu, 29 Oct 2020 04:12:13 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id g4sm3714021wmh.13.2020.10.29.04.12.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2020 04:12:12 -0700 (PDT) Subject: Re: Possible bug in getdents64()? To: Florian Weimer , Alejandro Colomar via Libc-alpha Cc: libc-help@sourceware.org, linux-man , "linux-kernel@vger.kernel.org" , "Michael Kerrisk (man-pages)" References: <829387c9-50d7-3d29-83bf-c4fec17cf9dd@gmail.com> <01065580-8602-52e6-0cca-22d1aa20a540@gmail.com> <87eelhthjj.fsf@oldenburg2.str.redhat.com> From: Alejandro Colomar Message-ID: <9d7e036a-e60c-0446-a263-c0cdc21fbdd4@gmail.com> Date: Thu, 29 Oct 2020 12:12:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <87eelhthjj.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 11:12:15 -0000 On 2020-10-29 12:09, Florian Weimer wrote: > * Alejandro Colomar via Libc-alpha: > >> [[ CC += linux-man, linux-kernel, libc-alpha, mtk ]] >> >> On 2020-10-28 20:26, Alejandro Colomar wrote: >>> The manual page for getdents64() says the prototype should be the >>> following: >>>        int getdents64(unsigned int fd, struct linux_dirent64 *dirp, >>>                     unsigned int count); >>> >>> Note the type of 'count': 'unsigned int' >>> (usually a 32-bit unsigned integer). >>> And the Linux kernel seems to use those types (fs/readdir.c:351): >>> SYSCALL_DEFINE3(getdents64, unsigned int, fd, >>>         struct linux_dirent64 __user *, dirent, >>>         unsigned int, count) >>> { >>> ... >>> } >>> But glibc uses 'size_t' (usually a 64-bit unsigned integer) >>> for the parameter 'count' (sysdeps/unix/linux/getdents64.c:25): >>> >>> /* The kernel struct linux_dirent64 matches the 'struct dirent64' type.  */ >>> ssize_t >>> __getdents64 (int fd, void *buf, size_t nbytes) >>> { >>>   /* The system call takes an unsigned int argument, and some length >>>      checks in the kernel use an int type.  */ >>>   if (nbytes > INT_MAX) >>>     nbytes = INT_MAX; >>>   return INLINE_SYSCALL_CALL (getdents64, fd, buf, nbytes); >>> } >>> libc_hidden_def (__getdents64) >>> weak_alias (__getdents64, getdents64) >>> >>> Isn't it undefined behavior to pass a variable of a different >>> (larger) type to a variadic function than what it expects? >>> Is that behavior defined in this implementation? >>> Wouldn't a cast to 'unsigned int' be needed? > > There is no variadic function involved here. INLINE_SYSCALL_CALL takes > care of the zero extension to the register internally, irrespective of > the argument type. (The register is of type long int or long long int, > depending on the architecture.) Hi Florian, Thank you very much! Alex > > Thanks, > Florian >