From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 518323973056 for ; Wed, 28 Oct 2020 19:27:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 518323973056 Received: by mail-wr1-x42d.google.com with SMTP id n15so324892wrq.2 for ; Wed, 28 Oct 2020 12:27:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=bIaz5Hu2eMsscrwhCaC6QzQ3sO3eV1CjyyuqoFMmrwM=; b=HFprUCJGHiR37A7TK4IiVISMZU9xVgeY6hAyqYtRGORfcVArEUBQMJylWZ04pL0eOr dj9DSohBkUL57gswFfdzmDT+oE5hC+F2JosohHeNuG68lI3l14QseHNa63J7cilhEx0V koEt1u4aSa8q19HklDH8EWAdB5gGVLWu4RT22rxNsduhoU/jOVvro7ppIZpDk7TgWqf9 PG2w7SmTehMZuxQbhfslzEZmeL9LfQgj1nFXBczzPoKu9vQXVWnAPgfMP9RXq+IVfKtQ Pq7X8XBjUo34ojTBh6dJP8aolN4KoKGS42yQdqAXgtCKfKlAPHC+RwmPQMHLsjswjnSG GAfQ== X-Gm-Message-State: AOAM532Wt3CqA9VVKQIr+s46X61rE7mllqFpWtvOPoorvE211pfX7MyO qxlejcWekxDfiYgS6E0XD3HFU1P7YEg= X-Google-Smtp-Source: ABdhPJy0IJjv5EQepDkUKK7NX3xNUx401sfbO9828Z2JILdEpCmgvhujoqjH68eDlEjbOPGoJLn06w== X-Received: by 2002:adf:f482:: with SMTP id l2mr1029247wro.26.1603913222062; Wed, 28 Oct 2020 12:27:02 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id f20sm513079wmc.26.2020.10.28.12.27.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 12:27:01 -0700 (PDT) To: libc-help@sourceware.org From: Alejandro Colomar Subject: Possible bug in getdents64()? Message-ID: <829387c9-50d7-3d29-83bf-c4fec17cf9dd@gmail.com> Date: Wed, 28 Oct 2020 20:26:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, 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: Wed, 28 Oct 2020 19:27:04 -0000 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? Thanks, Alex