From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23620 invoked by alias); 4 Apr 2015 11:18:13 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34845 Received: (qmail 10737 invoked from network); 4 Apr 2015 11:18:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1428145872; bh=0bXAAIgTa8ZAaVlYzINeAvOqhrcwvvUhMWdx3VQ3mS4=; h=cc:In-reply-to:From:References:To:Subject:Date:From:Subject; b=ksctcwr8JHstC9DVoSWQXlo7Z1iWkhmmdVW1U+J8OVOTQB4rRz++wOFhAuFlLKBMHgvMqzZCOw7TBM97gVUk9EE+R+ezU5gB+8xhQiCywkNNZ3k9eIIP9V+F3a+hGbwYawByNzIj5sChZ86zF7dox1QAFWKJvo52e4S15UvXeA79zRIZaOCQ90WA6sbXiGIs00nB91oJ5KvGzEgOLiP1F6WGZE7gdvo5KvJNIPu0FcwlcD02qJXOjWkPpOyt8hAK6xmXJnMwEd/TrRYWpe/Dt1JtYLf20Nmu9qLTn+BP2LN7/XTtfMTRXhCaWqjtDeV299EN2or0TrR7a+wyanRTLw== X-Yahoo-Newman-Id: 12013.14025.bm@smtp121.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oE99OuUVM1nJsQe1lqcmKBY.OmHU_8G0dGYKZ_99S1prit_ FW0brBeY0ofFdjPAkEPqKNdYbMBtHsk.yKCX102VGPjpf97NKIQId29FCEBx ef4t41Gk5py2E5ANASPJ2YSxWDc8GBC0StYiRj5O5D.gIoWo5mbJUmxQoj4A WElhWkZOHM0WPztKlEbVhAzzg_5YCD.qnLA2vKqTcmtqjZjH8kxwK5BIQzOp CxTGDuR2ZdrtfMYToJCXUt.T9ur4cdnVPzqjyoxi3HyZAcwM0Qcduayk1G3o cVgGVi8pQIOxDwKMlGEE1FMk1jBJzpbwbh4Bi.dFbepzl4gBpCW6iJLZufuT e0kfapc9vdp.42RaDFaMJeI9jqNj57jAuM9NRyilqoDBN8nkxjZnx1OfWWq9 3uv9AlKNthvCfJwFN4lfAlW7GU8wjnGDfT._2yXy_z.8dGNGA9RosbIAW361 A8NoP5T_WLBfJJkbmyUDDS55pvogEZthA7lO1h5eL32QKNOUT75Gn_x5x4it X4H3IQFCbdTUiJtuO_BMtEmKltOcOtQGu66XsYqGvLRXJMq7PGhvsveBvZXz mcywJHo1hcq4OdPCg4rh2_x.by_l9pnLNLt6LhC4c_EHnPcfqerFPaEPlboW OBQVcRkERq2AWRgxxCUGyEXnRz.8dFkYczViXn8IY6Eoydtz_73DVMzHXwKI fVQ-- X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- cc: zsh-workers@zsh.org In-reply-to: <1428069156-29982-1-git-send-email-oystwa@gmail.com> From: Oliver Kiddle References: <1428069156-29982-1-git-send-email-oystwa@gmail.com> To: =?UTF-8?q?=C3=98ystein=20Walle?= Subject: Re: [RFC PATCH] Allow grouping of thousands in format string MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <15441.1428145869.1@quattro> Content-Transfer-Encoding: 8bit Date: Sat, 04 Apr 2015 13:11:11 +0200 Message-ID: <15444.1428145871@quattro> Øystein Walle wrote: > Putting an apostrophe before i, d, u, f, F, g or G is specified in POSIX > albeit noted as an extension to ISO C. There's other printf features that were left out because they weren't portable at the time. %a %A and %F formats, for example. After looking around the ' flag is supported on any system I now have access to, even Solaris 8. However, I can't see a mention of it in the OpenBSD manpage: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/asprintf.3?query=printf&sec=3 Anyone have an OpenBSD system they can verify with? Even if it doesn't support the flag, it'd be good to know if it is just ignored or causes printf to fail. The flag is locale dependent anyway so being ignored is quite reasonable for zsh's printf. %a/A/F are in Solaris 10 which is a reasonable minimum to expect these days. Otherwise, they need OpenBSD 4.5 though I've no idea how common that still is. It'd be possible to test for them with autoconf but the documentation would need to mention that they depend on the C library implementing them. > Bash handles this this and from what I can tell implements it much in the same > way so that stuff like %'s is passed straight on to the system's printf(). > However POSIX also says that using the grouping specifier with other flags is > undefined. It works just fine on the limited range of systems I've tested it on > (all GNU). Is it undefined with other "flags" or with non-numeric format specifiers? It might be best to add a test case so we find out if the behaviour is undesirable on some other system. > If desired I could set a flag and then handle it further on by checking that > type == 2 or type == 3 or something like that, but that needs some rearranging. A flag is already set because it checks that flags aren't duplicated to avoid overflowing the spec buffer. It wouldn't need much rearranging but then it's not checking the type with other numeric only flags such as +. For a more general implementation, the flags array could be replaced by a single int and bit manipulation and it could set a bit mask for compatible flags in the switch statement. > int flags[5], *len; > char *start, *endptr, *c, *d, *flag, *buf = NULL, spec[13], *fmt = NULL; > - char **first, **argp, *curarg, *flagch = "0+- #", save = '\0', nullstr = '\0'; > + char **first, **argp, *curarg, *flagch = "'0+- #", save = '\0', nullstr = '\0'; I'm fairly sure that you'll also need to increment the size of the flags and spec arrays too. > - /* ignore any size modifier */ > - if (*c == 'l' || *c == 'L' || *c == 'h') c++; > + /* ignore any size modifier and grouping specifier */ > + if (*c == 'l' || *c == 'L' || *c == 'h' || *c == '\'') c++; I'm not convinced this part is right. Can you remember why you needed it? The ' flag comes before width specifiers and size modifiers. In, e.g. printf "%2\$10f\n" 1 2 the ' flag comes after the $ and not before the f. Oliver