From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 8A76A1F4C0 for ; Sun, 13 Oct 2019 20:12:30 +0000 (UTC) Received: from localhost ([::1]:42088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJkE9-0000Yg-3W for normalperson@yhbt.net; Sun, 13 Oct 2019 16:12:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38669) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJkE5-0000YY-29 for bug-gnulib@gnu.org; Sun, 13 Oct 2019 16:12:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJkE3-0004DO-TX for bug-gnulib@gnu.org; Sun, 13 Oct 2019 16:12:24 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:46348) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iJkE3-0004B5-Nf for bug-gnulib@gnu.org; Sun, 13 Oct 2019 16:12:23 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DDE42160690; Sun, 13 Oct 2019 13:12:21 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6bch3IHj-JsP; Sun, 13 Oct 2019 13:12:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2F5EA160694; Sun, 13 Oct 2019 13:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7UVKIgWAhJHG; Sun, 13 Oct 2019 13:12:21 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 09F74160690; Sun, 13 Oct 2019 13:12:21 -0700 (PDT) Subject: Re: supporting strings > 2 GB To: Bruno Haible References: <15256545.f1uGFDiRv1@omega> <749e79a7-0c0b-74d9-dbda-9a4676a931d2@cs.ucla.edu> <1779544.eJvvWEHBEu@omega> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sun, 13 Oct 2019 13:12:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1779544.eJvvWEHBEu@omega> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On 10/13/19 12:50 PM, Bruno Haible wrote: > The C or POSIX standards deal only with layer 1). However, layer 2) is > essential for programs, to make the use of the new APIs easy. Right, and I see the need for two layers. I'm still not seeing, though, the exact division between the two layers in this instance. With large file support, POSIX took an old function lseek that used 'long', and said that lseek should use the new type 'off_t' instead. Old implementations could simply add 'typedef long off_t;' and conform. There is no OFF_MAX or PRIdOFF because off_t is not part of ISO C. Programs define _FILE_OFFSET_BITS to choose which off_t they get. A difference here is that we'd be proposing a change to ISO C (it could be done only in POSIX, but it's really a change to the C standard). In ISO C there's a tradition that types like 'ptrdiff_t' all have macros like PTRDIFF_MAX, PRIdPTR, etc., and so presumably this tradition should apply to printf_len_t. If we take this approach, there should be no need for %ln vs %n or %**d vs %*d; programs that define _PRINTF_LARGE will get a wide printf_len_t and things will "just work" if programs consistently use printf_len_t instead of int (and use the related macros too).