A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1771 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1771 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Christoph Anton Mitterer Organization: User Reference: Section: Utilities / printf Page Number: 3269 Line Number: 111019 Final Accepted Text: See https://austingroupbugs.net/view.php?id=1771#c6439. Resolution: Accepted As Marked Fixed in Version: ====================================================================== Date Submitted: 2023-08-07 19:22 UTC Last Modified: 2023-09-02 09:01 UTC ====================================================================== Summary: support or reserve %q as printf-utility format specifier ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001774 Support ' <apostrophe> as a forma... ======================================================================
---------------------------------------------------------------------- (0006453) geoffclare (manager) - 2023-09-02 09:01 https://austingroupbugs.net/view.php?id=1771#c6453 ---------------------------------------------------------------------- > My point is that there's a much better way for printf(1) and printf(3) to > output numbers in arbitrary bases that has been in use for almost 30 years > (in ksh93). I'd rather C and POSIX specify that rather than that new %b If this issue had come to light 6 months ago, it might have been possible to persuade the C committee to do that. Unfortunately, C23 is now set in stone. > Perhaps a better question might be why we'd even consider deprecating > any functionality, which is all of: widely supported, used by applications, > and has no current standard alternative. Surely the proper procedure in > that case is to specify something that can be used as the alternative first, > and deprecate once that is available. If we don't deprecate %b now, the alternative is to deprecate it in Issue 9 at the same time as adding %#s, and change %b in Issue 10, which would mean Issue 9 will have an inconsistency between the printf() function and the printf utility. At least, those are the options if we honour the intention for draft 3 to have been feature-complete. I suppose we could also consider making this case an exception, given that we are "caught between a rock and a hard place", and add %#s in draft 4. There is already a patch for coreutils printf, but I think we would need buy-in from at least one other printf implementation to even consider doing that. Issue History Date Modified Username Field Change ====================================================================== 2023-08-07 19:22 calestyo New Issue 2023-08-07 19:22 calestyo Name => Christoph Anton Mitterer 2023-08-07 19:22 calestyo Section => Utilities / printf 2023-08-07 19:22 calestyo Page Number => 3269 2023-08-07 19:22 calestyo Line Number => 111019 2023-08-07 19:36 chet_ramey Note Added: 0006416 2023-08-07 19:46 calestyo Note Added: 0006417 2023-08-07 23:39 salewski Issue Monitored: salewski 2023-08-08 08:46 geoffclare Note Added: 0006418 2023-08-08 14:28 calestyo Note Added: 0006420 2023-08-08 15:04 geoffclare Note Added: 0006421 2023-08-08 17:10 calestyo Note Added: 0006422 2023-08-08 18:45 eblake Note Added: 0006423 2023-08-08 20:40 jsm28 Note Added: 0006424 2023-08-08 20:53 calestyo Note Added: 0006425 2023-08-31 16:10 Don Cragun Note Added: 0006439 2023-08-31 16:13 Don Cragun Final Accepted Text => See https://austingroupbugs.net/view.php?id=1771#c6439. 2023-08-31 16:13 Don Cragun Status New => Resolved 2023-08-31 16:13 Don Cragun Resolution Open => Accepted As Marked 2023-08-31 16:14 Don Cragun Tag Attached: issue8 2023-08-31 17:46 eblake Relationship added related to 0001774 2023-08-31 17:48 eblake Note Added: 0006440 2023-08-31 17:49 eblake Note Edited: 0006440 2023-08-31 18:33 eblake Note Added: 0006441 2023-08-31 22:00 eblake Note Added: 0006442 2023-09-01 01:23 kre Note Added: 0006443 2023-09-01 01:40 kre Note Added: 0006444 2023-09-01 01:43 kre Note Edited: 0006443 2023-09-01 08:40 geoffclare Note Added: 0006445 2023-09-01 12:00 eblake Note Added: 0006446 2023-09-01 12:03 eblake Note Edited: 0006446 2023-09-01 12:29 stephane Note Added: 0006447 2023-09-01 12:30 stephane Note Edited: 0006447 2023-09-01 12:32 stephane Note Edited: 0006447 2023-09-01 14:00 geoffclare Note Added: 0006448 2023-09-01 14:17 chet_ramey Note Added: 0006449 2023-09-01 17:55 stephane Note Added: 0006450 2023-09-01 18:37 kre Note Added: 0006451 2023-09-01 19:02 stephane Note Added: 0006452 2023-09-02 09:01 geoffclare Note Added: 0006453 ======================================================================
