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 DFDD61F4C0 for ; Sun, 13 Oct 2019 03:02:06 +0000 (UTC) Received: from localhost ([::1]:37292 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJU8z-0008JA-8n for normalperson@yhbt.net; Sat, 12 Oct 2019 23:02:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59520) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJU8v-0008Ip-On for bug-gnulib@gnu.org; Sat, 12 Oct 2019 23:02:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJU8u-0004EF-52 for bug-gnulib@gnu.org; Sat, 12 Oct 2019 23:02:01 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52166) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iJU8t-0004CB-Vb for bug-gnulib@gnu.org; Sat, 12 Oct 2019 23:02:00 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 73B57160661; Sat, 12 Oct 2019 20:01:55 -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 U1ZFZeR75YQt; Sat, 12 Oct 2019 20:01:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B04471605D8; Sat, 12 Oct 2019 20:01:54 -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 EMfjht9SDB-R; Sat, 12 Oct 2019 20:01:54 -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 8659516068A; Sat, 12 Oct 2019 20:01:54 -0700 (PDT) Subject: Re: supporting strings > 2 GB To: Bruno Haible References: <15256545.f1uGFDiRv1@omega> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <749e79a7-0c0b-74d9-dbda-9a4676a931d2@cs.ucla.edu> Date: Sat, 12 Oct 2019 20:01:54 -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: <15256545.f1uGFDiRv1@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/12/19 7:38 AM, Bruno Haible wrote: > Has this already been discussed in the Austin Group, or on the glibc list? Not as far as I know, though I haven't read all those mailing lists. It would be a good thing to do. I'm not sold on a new type 'printf_len_t' in the standard. Can't we get by with using ptrdiff_t instead? That would save standard C libraries the hassle of specifying a new length modifier and/or macros like PRIdPRINTF and SCNdPRINTF, for programs that want to print or read printf_len_t values. Gnulib may need something like printf_len_t, PRIdPRINTF etc., but I don't quite see why POSIX and/or the C standard would need them. >> 3) Introduce %ln as a printf_len_t alternative to %n. Would %ln work only for the new *l functions, or would it also work for the already-standard printf functions? How about the '*' field width? There needs to be some way to say that the field width is of type ptrdiff_t, not int. Would '**' stand for ptrdiff_t field widths? Perhaps it would be simpler if the new *l functions use ptrdiff_t everywhere that the old functions use 'int' for sizes and widths. Then we wouldn't have to worry about '**' vs '*', or about '%ln' versus '%n'. The Gnulib layer could resolve whether the functions are about int or ptrdiff_t. I assume functions like snprintfl would take ptrdiff_t arguments instead of size_t arguments for buffer sizes. Basically, replace size_t and int with ptrdiff_t everywhere we can.