From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BFA6C63777 for ; Sun, 22 Nov 2020 22:33:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B8BFD20724 for ; Sun, 22 Nov 2020 22:33:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="V+XoCaj0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726736AbgKVWcp (ORCPT ); Sun, 22 Nov 2020 17:32:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726489AbgKVWco (ORCPT ); Sun, 22 Nov 2020 17:32:44 -0500 Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B93F1C0613CF; Sun, 22 Nov 2020 14:32:44 -0800 (PST) Received: by mail-oi1-x241.google.com with SMTP id c80so17644806oib.2; Sun, 22 Nov 2020 14:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=xz3AjGP9Tg1tyJ2aOnoC1uR/QewegNTFrIVqLnCw6+Q=; b=V+XoCaj0JS9lqwpClskQX7XEqiJpcnUhg3raB41mKRAIOH0j7s1JqmuMVnzINkw+Y9 6U1gXIcD+CJ59ICIZpbSgo5+t88xtZ89aCzC5ANQ2Nf4HeNBrMJvaiLVaAdKjx4taqGL cwgvqFMkvJPPoDnQG0ymiTXYEjbkzkLTVOkXQ4fEuBIdTNmx9L9b0ZT8wwnTeA4JdELO vdbA51hu1oTjrXDAIJzcnPz7GVd5lZAjzbqAwM9BjT3m+O13Ih/qaPCjupt+m9WmCAXB mUsd8nLuWilrZQm2sDZPua79J4up14WsW8K7aa+mVHVOzdlJpvMTItPvxifvstJaeJ8D ofhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=xz3AjGP9Tg1tyJ2aOnoC1uR/QewegNTFrIVqLnCw6+Q=; b=okfnGOtGbC7wMzI6j1Jq29YRwUjF5Jm0W5OiHMLNjTBuYX6cvlziDLLuHPJKDL+Nqm N5MjWELmdVnUz4FBDQfKh4UWDlMU2loZw5m3Kr1YORtjcHYUQLuYFaYLQo2YBYo8CGPs uG8N/S2sCZhY7a6VKGIm+BeFNEr8Z4p43vhyUy6CZoK9s5EQQ3SjNbbpn8QPzmFu9SLs 3/cr3SdwgYdObevEg+GslsLAJlUuwXXiqI9anurzfwDPaTePsZHKgd3yVSEAAp/7RdIm 2VhbpGXafmxrgpQ+9QEj09qemOKIRQPE89vHHjgSKHsTm0obnh4b3HaG3t+kQJhMczpF XtRw== X-Gm-Message-State: AOAM533Zbfb0QmnE9WgBDtK3MeJD/Q+z1ATuzAsjxsImbe3T+yLw5X89 F35JqAL+F8A9FHXqYBSFAfgxPiwoLq84iOa0FqnzKhTiP14= X-Google-Smtp-Source: ABdhPJwc0YCoO8vpqFyniYpcRUJUUJMZa2O3jH5OoxaN0/W+5NG3GKJFXVMd/J5npOqMIihgCv1CgFKUicCnWjoAx7w= X-Received: by 2002:a05:6808:91a:: with SMTP id w26mr13508860oih.159.1606084364053; Sun, 22 Nov 2020 14:32:44 -0800 (PST) MIME-Version: 1.0 References: <20201121173054.12172-1-alx.manpages@gmail.com> In-Reply-To: <20201121173054.12172-1-alx.manpages@gmail.com> Reply-To: mtk.manpages@gmail.com From: "Michael Kerrisk (man-pages)" Date: Sun, 22 Nov 2020 23:32:32 +0100 Message-ID: Subject: Re: [PATCH] lseek.2: SYNOPSIS: Use correct types To: Alejandro Colomar Cc: linux-man , lkml , "libc-alpha@sourceware.org" , Florian Weimer Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Adding libc-alpha@ here, so someone might correct me if I make a misstep] Hello Alex, On Sat, 21 Nov 2020 at 18:34, Alejandro Colomar wrote: > > The Linux kernel uses 'unsigned int' instead of 'int' > for 'fd' and 'whence'. > As glibc provides no wrapper, use the same types the kernel uses. I see Florian already replied, but just to add a detail or two... In general, the manual pages explicitly note the APIs that have no glibc wrapper. (If not, that's a bug in the page, but I don't expect there are many such bugs.) Looking in , we have: [[ #ifndef __USE_FILE_OFFSET64 extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW; #else # ifdef __REDIRECT_NTH extern __off64_t __REDIRECT_NTH (lseek, (int __fd, __off64_t __offset, int __whence), lseek64); # else # define lseek lseek64 # endif #endif #ifdef __USE_LARGEFILE64 extern __off64_t lseek64 (int __fd, __off64_t __offset, int __whence) __THROW; #endif ]] It looks to me like there's a prototype hiding in there. (And yes, I don't find it so funny to decode the macro logic either.) Thanks, Michael PS By the way, be aware that the code of many wrapper functions is autogenerated from "syscalls.list" files in the glibc source, for example, sysdeps/unix/sysv/linux/syscalls.list. This isn't the case for lseek(), though, as far as I can see; I think the wrapper function is defined in sysdeps/unix/sysv/linux/lseek.c. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/