Mantis is seeing mail bounces today 26 Oct
Andrew- Is there a problem with austin-group-l today (around noon CDT 26 Oct)? Mantis is getting bounces for some notification mails to the group. Mark Mark Brown ms_br...@sbcglobal.net
[Issue 8 drafts 0001325]: Allow make to remake an included file
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-10-26 16:57 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == -- (0005068) rhansen (manager) - 2020-10-26 16:57 https://austingroupbugs.net/view.php?id=1325#c5068 -- > Historical versions of GNU make delay the use of the rule until after all makefiles have been read, That is true, but... > which means that a rule for an include file cannot be defined in an earlier include file (that itself needs to be made via a rule). I don't think that is correct. With the following files, make foo (GNU Make 4.3) properly builds a.mk and foo: # Makefile include a.mk -include b.mk # a.mk b.mk: printf 'foo:\n\techo foo >foo\n' >b.mk Here is the script I used to test: #!/bin/sh d=$(mktemp -d) || exit 1 trap 'rm -rf "$d"' EXIT cd "$d" && printf -- 'include a.mk\n-include b.mk\n' >Makefile && printf 'b.mk:\n\tprintf '\''foo:\\n\\techo foo >foo\\n'\'' >b.mk\n' >a.mk && make foo && [ -f foo ] Furthermore, GNU Make 4.3 allows the rule for an include file to be defined after the include line like this: # Makefile -include a.mk include b.mk # b.mk a.mk: printf 'foo:\n\techo foo >foo\n' >a.mk Here is the script I used to test: #!/bin/sh d=$(mktemp -d) || exit 1 trap 'rm -rf "$d"' EXIT cd "$d" && printf -- 'include a.mk\n-include b.mk\n' >Makefile && printf 'b.mk:\n\tprintf '\''foo:\\n\\techo foo >foo\\n'\'' >b.mk\n' >a.mk && make foo && [ -f foo ] Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 ==
[Issue 8 drafts 0001325]: Allow make to remake an included file
The following issue has been UPDATED. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 Resolution: Reopened Fixed in Version: == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-10-26 17:08 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == -- (0005069) nick (manager) - 2020-10-26 17:08 https://austingroupbugs.net/view.php?id=1325#c5069 -- Reopening in the light of https://austingroupbugs.net/view.php?id=1415 Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened ==
[Issue 8 drafts 0001325]: Allow make to remake an included file
The following issue has been set PARENT OF issue 0001415. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-10-26 15:54 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 ==
[1003.1(2004)/Issue 6 0001415]: The text added as a result of Issue #1325 is unacceptable
The following issue has been set CHILD OF issue 0001325. == https://austingroupbugs.net/view.php?id=1415 == Reported By:psmith Assigned To:ajosey == Project:1003.1(2004)/Issue 6 Issue ID: 1415 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Under Review Name: Paul Smith Organization: GNU Project User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2020-10-26 16:43 UTC Last Modified: 2020-10-26 16:54 UTC == Summary:The text added as a result of Issue #1325 is unacceptable == Relationships ID Summary -- child of0001325 Allow make to remake an included file == Issue History Date ModifiedUsername FieldChange == 2020-10-26 16:43 psmith New Issue 2020-10-26 16:43 psmith Status New => Under Review 2020-10-26 16:43 psmith Assigned To => ajosey 2020-10-26 16:43 psmith Name => Paul Smith 2020-10-26 16:43 psmith Organization => GNU Project 2020-10-26 16:43 psmith Section => (section number or name, can be interface name) 2020-10-26 16:43 psmith Page Number => (page or range of pages) 2020-10-26 16:43 psmith Line Number => (Line or range of lines) 2020-10-26 16:54 nick Relationship added child of 0001325 ==
Re: printf (the utility) expected range of integer values
Date:Mon, 26 Oct 2020 15:02:26 +0100 From:Joerg Schilling Message-ID: <5f96d6f2.jkFuBT5X4/F/wqwv%joerg.schill...@fokus.fraunhofer.de> | If the code you are using is from FreeBSD (Garret Damore) Where it originated I don't know for sure, but it has been in the NetBSD source tree since 1993, which I think means it came from a CSRG BSD distribution (the log doesn't indicate explicitly) - after whjch it has had numerous fixes an updates by various NetBSD developers over the (many) years. The code does contain a (no longer used, that is, #if 0 surrounded) sccsid from CSRG: static char sccsid[] = "@(#)printf.c8.2 (Berkeley) 3/22/95"; but that appeared when 4.4-lite2 was merged in 1997, the original in the NetBSD source tree contained static char sccsid[] = "@(#)printf.c 5.9 (Berkeley) 6/1/90"; if that's any help for you to work out the lineage and/or compare it to the FreeBSD version if that is (for some reason) relevant to anything. But none of this is the issue, our code does the same thing as bosh/bash/dash/yash for the issues in question. Those are related to what the standard actually requires, rather than what any of the current implementations actually does (except in as much as those indicate what the standard should say). The following has absolutely nothing to do with the issue I raised, but since you included it: | The code from bosh has been written from scratch to fully support | %n$ and this is what we should add to the standard in the near future. I'm not sure this is really required in the printf utility, as distinct from the printf (family of) functions, and causes all kinds of issues because of the way the utility reprocesses the format over and over until the args have all been used. Eg: consider printf '%1$d %4$d %2$d\n' 1 2 3 4 5 6 7 8 9 10 11 12 What is supposed to be printed from that? Bosh appears to print 1 4 2 5 8 6 9 12 10 Now consider some other locale (the only reason for supporting this stuff at all is when locales need to print the args in different orders or different actual args, in order to correctly represent the language conventions) where the format string that is used is '%1$d %3$d %2$d\n' With that one, bosh prints 1 3 2 4 6 5 7 9 8 10 12 11 Now it has run the format string 4 times instead of just 3 previously, and has printed all the args, whereas previously it never printed 3 7 or 11. How is this useful? For this, I'm not blaming the bosh printf implementation, given what it is being asked to do, there is very little else that it can do, though in the first example, after args 1 4 and 2 were used, it could have removed them and left 3 5 6 7 8 9 10 11 12 for the next iteration of the format string. I cannot think of a sane use for this, but at least it would end up using all of the args, and always run the format string the same number of times (presuming all formats actually consume the same number of args). The problem really is that where this method was invented, for printf() the function, the format string is only ever used once, if some of the args are never used, they're simply ignored. That can be used in a sensible way. With printf re-using the format string it really can't. One possible solution would be that if any n$ strings appear in the format string conversions, then the format is not restarted, even if all of the args are not consumed. That might make the system workable (as it then makes it equivalent to printf()). But that isn't what bosh does. kre
Re: printf (the utility) expected range of integer values
Robert Elz wrote: > Date:Mon, 26 Oct 2020 15:02:26 +0100 > From:Joerg Schilling > Message-ID: > <5f96d6f2.jkFuBT5X4/F/wqwv%joerg.schill...@fokus.fraunhofer.de> > > | If the code you are using is from FreeBSD (Garret Damore) > > Where it originated I don't know for sure, but it has been in the NetBSD > source tree since 1993, which I think means it came from a CSRG BSD > distribution (the log doesn't indicate explicitly) - after whjch it has had > numerous fixes an updates by various NetBSD developers over the (many) years. > > The code does contain a (no longer used, that is, #if 0 surrounded) > sccsid from CSRG: > static char sccsid[] = "@(#)printf.c8.2 (Berkeley) 3/22/95"; > but that appeared when 4.4-lite2 was merged in 1997, the original > in the NetBSD source tree contained > static char sccsid[] = "@(#)printf.c 5.9 (Berkeley) 6/1/90"; OK, I checked the NetBSD repoand it does not see to be related to the FreeBSD version. > The following has absolutely nothing to do with the issue I raised, but > since you included it: > > | The code from bosh has been written from scratch to fully support > | %n$ and this is what we should add to the standard in the near future. > > I'm not sure this is really required in the printf utility, as distinct > from the printf (family of) functions, and causes all kinds of issues > because of the way the utility reprocesses the format over and over until > the args have all been used. We are currently adding gettext(1) to POSIX and you need support for %n$ if you like to use gettext in a useful way in shell scripts. > Eg: consider > > printf '%1$d %4$d %2$d\n' 1 2 3 4 5 6 7 8 9 10 11 12 > > What is supposed to be printed from that? > > Bosh appears to print > > 1 4 2 > 5 8 6 > 9 12 10 This is the identical output to what you get from ksh93 and from the FreeBSD printf. What you see is a side effect from the two constraints: 1) Be compatible to the current POSIX standard 2) Support %n$ in a useful way > Now consider some other locale (the only reason for supporting this > stuff at all is when locales need to print the args in different orders > or different actual args, in order to correctly represent the language > conventions) where the format string that is used is > > '%1$d %3$d %2$d\n' > > With that one, bosh prints > > 1 3 2 > 4 6 5 > 7 9 8 > 10 12 11 > > Now it has run the format string 4 times instead of just 3 previously, > and has printed all the args, whereas previously it never printed 3 7 or 11. > > How is this useful? This is the identical output to what you get from ksh93 and from the FreeBSD printf. There is a simple rule of thumb: If you like to use %n$ for localization, use a matching number of arguments and % units with printf(1). Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: printf (the utility) expected range of integer values
Date:Mon, 26 Oct 2020 19:18:10 +0100 From:Joerg Schilling Message-ID: <5f9712e2.+zlga0iaqihkovkz%joerg.schill...@fokus.fraunhofer.de> | There is a simple rule of thumb: If you like to use %n$ for localization, | use a matching number of arguments and % units with printf(1). This is the problem, in two ways ... it isn't good enough to define something in a way where to usefully use it you also need to add a "simple rule of thumb" - much better to simply specify something that actually works, and only define it to work when used that way. Getting meaningless output from multiple implementations that copied each other (one did it first, badly, then the others copied) is not useful. Can you think of any rational use of a format with %n$ conversions where you would ever want to process the format string more than once? If not, why not just forbid it (and fix the implementations that now exist). Second, like a lot of localisation issues, all of this is too intertwined with what is needed to support European languages. It isn't always possible to follow that rule of thumb with other languages where additional elements may need to be added (or not added) to certain sentences. kre
[Issue 8 drafts 0001325]: Allow make to remake an included file
The following issue has been REOPENED. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-10-26 22:34 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review ==
[Issue 8 drafts 0001325]: Allow make to remake an included file
The following issue has been UPDATED. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Under Review Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-10-26 22:34 UTC == Summary:Allow make to remake an included file == Relationships ID Summary -- parent of 0001415 The text added as a result of Issue #13... == Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 2020-10-26 15:54 geoffclare Tag Attached: issue8 2020-10-26 16:54 nick Relationship added parent of 0001415 2020-10-26 16:57 rhansenNote Added: 0005068 2020-10-26 16:58 rhansenNote Edited: 0005068 2020-10-26 17:00 rhansenNote Edited: 0005068 2020-10-26 17:08 nick Note Added: 0005069 2020-10-26 17:08 nick Resolution Accepted As Marked => Reopened 2020-10-26 22:34 nick Status Resolved => Under Review ==
[1003.1(2004)/Issue 6 0001415]: The text added as a result of Issue #1325 is unacceptable
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1415 == Reported By:psmith Assigned To:ajosey == Project:1003.1(2004)/Issue 6 Issue ID: 1415 Category: Shell and Utilities Type: Clarification Requested Severity: Objection Priority: normal Status: Under Review Name: Paul Smith Organization: GNU Project User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Interp Status: --- Final Accepted Text: == Date Submitted: 2020-10-26 16:43 UTC Last Modified: 2020-10-26 16:43 UTC == Summary:The text added as a result of Issue #1325 is unacceptable Description: I apologize if I'm not following the correct procedure but I'm not able to add notes to #1325 so I am opening a new issue as an objection. The text added as a resolution to issue #1325 is not acceptable. Regardless of the opinions of maintainers of other versions of make, the behavior of GNU make with respect to rebuilding included makefiles is every bit as legitimate a solution and there's no standardized precedent to require otherwise. In fact, GNU make's behavior is PREFERABLE because it does not require that users define rules that rebuild makefiles before the include line is parsed in the makefile. The order of rules vs. include lines is not relevant. GNU make is, pretty much unarguably, the single most widely used version of make existing today and its behavior in this area has been consistent and valid for 30 years or so. There's no justification for the POSIX committee to suddenly declare that such a widely-used implementation does not meet the standard. It is not, as described by the changes proposed in #1325, "historical" and it will not be, as I have explained many, many times to Joerg, changed in the future, not even to satisfy a POSIX standard if this text is left as-is. It is also, as I have also tried to explain many times, not an error, not misbehavior, and it does not cause failures when parallel builds are present _IF_ the makefile properly declares its prerequisite relationships. There IS a problem with rebuilding makefiles if you do NOT declare all of your prerequisite relationships, but it has nothing to do with whether included makefiles are built at the same time as the include line is parsed, and it is not even related to rebuilding makefiles: the same issue can be seen in other situations: the problem has to do with GNU make's directory cache implementation. Desired Action: Either revert the text of #1325 or else modify it so that GNU make's behavior (delaying the rebuild of included makefiles until the entire makefile and all other included makefiles are parsed) is explicitly allowed. == Issue History Date ModifiedUsername FieldChange == 2020-10-26 16:43 psmith New Issue 2020-10-26 16:43 psmith Status New => Under Review 2020-10-26 16:43 psmith Assigned To => ajosey 2020-10-26 16:43 psmith Name => Paul Smith 2020-10-26 16:43 psmith Organization => GNU Project 2020-10-26 16:43 psmith Section => (section number or name, can be interface name) 2020-10-26 16:43 psmith Page Number => (page or range of pages) 2020-10-26 16:43 psmith Line Number => (Line or range of lines) ==
[1003.1(2016/18)/Issue7+TC2 0001220]: Add an API to query the name of a locale category of a locale object
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1220 == Reported By:bhaible Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1220 Category: System Interfaces Type: Omission Severity: Editorial Priority: normal Status: New Name: Bruno Haible Organization: GNU User Reference: Section:--- Page Number:--- Line Number:--- Interp Status: --- Final Accepted Text: == Date Submitted: 2018-12-20 13:46 UTC Last Modified: 2020-10-26 16:16 UTC == Summary:Add an API to query the name of a locale category of a locale object == -- (0005067) geoffclare (manager) - 2020-10-26 16:16 https://austingroupbugs.net/view.php?id=1220#c5067 -- Re note 5065, environment variables are not always used (and if they are used, then they can simply be queried with getenv()). If an application calls:setlocale(LC_NUMERIC, locale1); setlocale(LC_TIME, locale2);then getlocalename_l(LC_ALL, LC_GLOBAL_LOCALE) would have to return, somehow, the information that the locale name for LC_NUMERIC is locale1, for LC_TIME is locale2, and for all other categories is "C" or "POSIX". With locale objects, in order to modify a locale and restore later there is no need to query locale names. It can be done using the existing locale_t handling functions (i.e. duplocale(), newlocale(), uselocale(), and freelocale()). Issue History Date ModifiedUsername FieldChange == 2018-12-20 13:46 bhaibleNew Issue 2018-12-20 13:46 bhaibleName => Bruno Haible 2018-12-20 13:46 bhaibleOrganization => GNU 2018-12-20 13:46 bhaibleSection => --- 2018-12-20 13:46 bhaiblePage Number => --- 2018-12-20 13:46 bhaibleLine Number => --- 2020-10-05 11:11 geoffclare Note Added: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 15:45 bhaibleNote Added: 0005027 2020-10-05 17:57 shware_systems Note Added: 0005030 2020-10-05 17:58 shware_systems Note Edited: 0005030 2020-10-07 13:29 geoffclare Note Added: 0005035 2020-10-07 15:08 shware_systems Note Added: 0005037 2020-10-23 14:21 geoffclare Note Added: 0005059 2020-10-23 15:57 shware_systems Note Added: 0005062 2020-10-26 10:03 geoffclare Note Added: 0005063 2020-10-26 14:50 shware_systems Note Added: 0005065 2020-10-26 16:16 geoffclare Note Added: 0005067 ==
[Issue 8 drafts 0001325]: Allow make to remake an included file
The following issue has been RESOLVED. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: Resolved Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text:https://austingroupbugs.net/view.php?id=1325#c5066 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-10-26 15:54 UTC == Summary:Allow make to remake an included file == Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 2020-10-26 15:54 geoffclare Page Number => (page or range of pages) 2020-10-26 15:54 geoffclare Line Number => (Line or range of lines) 2020-10-26 15:54 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1325#c5066 2020-10-26 15:54 geoffclare Status New => Resolved 2020-10-26 15:54 geoffclare Resolution Open => Accepted As Marked 2020-10-26 15:54 geoffclare version => Draft 1 ==
[Issue 8 drafts 0001325]: Allow make to remake an included file
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1325 == Reported By:dmitry_goncharov Assigned To: == Project:Issue 8 drafts Issue ID: 1325 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Dmitry Goncharov Organization: User Reference: Section:(section number or name, can be interface name) Page Number:(page or range of pages) Line Number:(Line or range of lines) Final Accepted Text: == Date Submitted: 2020-02-09 17:17 UTC Last Modified: 2020-10-26 15:53 UTC == Summary:Allow make to remake an included file == -- (0005066) geoffclare (manager) - 2020-10-26 15:53 https://austingroupbugs.net/view.php?id=1325#c5066 -- In Issue 8 draft 1 page 2892 lines 97098-97102 (make extended description), change:If the file does not exist in this location, it is unspecified whether additional directories are searched. If the file cannot be opened, and if the word include was prefixed with a character, the file shall be ignored. Otherwise, if the file cannot be opened an error shall occur.to:If a target rule or inference rule for the pathname has been parsed before the include line is parsed make shall use the rule to attempt to create the file or to bring it up to date before opening the file. If the pathname is relative, the file does not exist, and it cannot be created using such a rule, it is unspecified whether additional directories are searched for an existing file of the same relative pathname. If, after applying such a rule (if any), the file cannot be opened, and if the word include was prefixed with a character, the file shall be ignored. Otherwise, if the file cannot be opened an error shall occur. In issue 8 draft 1 page 2911 after line 97926 (make rationale), insert a new paragraph:This standard specifies that if a target rule or inference rule for an include line pathname has been parsed before the include line is parsed, make will use the rule to attempt to create the file or to bring it up to date before opening the file. Historical versions of GNU make delay the use of the rule until after all makefiles have been read, which means that a rule for an include file cannot be defined in an earlier include file (that itself needs to be made via a rule). Historical versions of BSD make do not attempt to (re-)make the include file. This standard also specifies that an include file is first (re-)made if possible, and only if not possible can other directories be searched. Historical versions of GNU make first search the include directories, then attempt to (re-)make the include file(s) in reverse order of the include line's appearance in the makefile. Issue History Date ModifiedUsername FieldChange == 2020-02-09 17:17 dmitry_goncharovNew Issue 2020-02-09 17:17 dmitry_goncharovName => Dmitry Goncharov 2020-02-09 17:17 dmitry_goncharovSection => (section number or name, can be interface name) 2020-02-09 18:29 shware_systems Note Added: 0004780 2020-02-10 13:27 joerg Note Added: 0004781 2020-02-10 13:28 joerg Note Edited: 0004781 2020-10-26 15:52 geoffclare Project Online Pubs => Issue 8 drafts 2020-10-26 15:53 geoffclare Note Added: 0005066 ==
[1003.1(2016/18)/Issue7+TC2 0001220]: Add an API to query the name of a locale category of a locale object
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1220 == Reported By:bhaible Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1220 Category: System Interfaces Type: Omission Severity: Editorial Priority: normal Status: New Name: Bruno Haible Organization: GNU User Reference: Section:--- Page Number:--- Line Number:--- Interp Status: --- Final Accepted Text: == Date Submitted: 2018-12-20 13:46 UTC Last Modified: 2020-10-26 14:50 UTC == Summary:Add an API to query the name of a locale category of a locale object == -- (0005065) shware_systems (reporter) - 2020-10-26 14:50 https://austingroupbugs.net/view.php?id=1220#c5065 -- Nothing in Note: 5037 implies multiple locale names are to be returned, mimicing setlocale(). The LC_ALL and LANG environment values are just a single name. That was someone's invention during that call this was the intent and I agree it would be nonsensical to do it. We've even argued at other times it's non-sensical for setlocale() to require it to begin with. The primary reason this makes sense is it simplifies library routines that modify aspects of a locale but then are expected to reset them to the original LC_ALL value. Without a means to query the object for this name a separate parameter to the function is required to specify that value, since the function has no way of knowing a previous name returned after a change is the same as that LC_ALL name, nor that LC_ALL in the environment hasn't been modified. Issue History Date ModifiedUsername FieldChange == 2018-12-20 13:46 bhaibleNew Issue 2018-12-20 13:46 bhaibleName => Bruno Haible 2018-12-20 13:46 bhaibleOrganization => GNU 2018-12-20 13:46 bhaibleSection => --- 2018-12-20 13:46 bhaiblePage Number => --- 2018-12-20 13:46 bhaibleLine Number => --- 2020-10-05 11:11 geoffclare Note Added: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 15:45 bhaibleNote Added: 0005027 2020-10-05 17:57 shware_systems Note Added: 0005030 2020-10-05 17:58 shware_systems Note Edited: 0005030 2020-10-07 13:29 geoffclare Note Added: 0005035 2020-10-07 15:08 shware_systems Note Added: 0005037 2020-10-23 14:21 geoffclare Note Added: 0005059 2020-10-23 15:57 shware_systems Note Added: 0005062 2020-10-26 10:03 geoffclare Note Added: 0005063 2020-10-26 14:50 shware_systems Note Added: 0005065 ==
Re: printf (the utility) expected range of integer values
Robert Elz via austin-group-l at The Open Group wrote: > I should have included dash and yash in that list - their error messages > are very similar to what /usr/bin/printf on NetBSD prints (and the NetBSD sh, > which uses the same source code for its builtin printf), but when I looked > closer, I can see they are not actually the same - so those clearly have > a builtin printf as well (they behave the same way as bash, the NetBSD sh > and bosh). If the code you are using is from FreeBSD (Garret Damore) then there are some minor bugs in it. Sorry, I no longer remember the exact problems The code from bosh has been written from scratch to fully support %n$ and this is what we should add to the standard in the near future. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
[1003.1(2016/18)/Issue7+TC2 0001414]: rewind() clears the error indicator, but when?
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1414 == Reported By:kre Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1414 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section:XSH 3.rewind Page Number:1821 (for info: in 202x d1.1 it is page 1740) Line Number:90114 (in 202x d1.1 it is line 57200) Interp Status: --- Final Accepted Text: == Date Submitted: 2020-10-25 17:51 UTC Last Modified: 2020-10-26 10:35 UTC == Summary:rewind() clears the error indicator, but when? == -- (0005064) geoffclare (manager) - 2020-10-26 10:35 https://austingroupbugs.net/view.php?id=1414#c5064 -- The text in question is derived directly from C99, so we should liaise with the C committee on this issue. Issue History Date ModifiedUsername FieldChange == 2020-10-25 17:51 kreNew Issue 2020-10-25 17:51 kreName => Robert Elz 2020-10-25 17:51 kreSection => XSH 3.rewind 2020-10-25 17:51 krePage Number => 1821 (for info: in 202x d1.1 it is page 1740) 2020-10-25 17:51 kreLine Number => 90114 (in 202x d1.1 it is line 57200) 2020-10-26 10:34 geoffclare Tag Attached: c99 2020-10-26 10:35 geoffclare Note Added: 0005064 ==
[1003.1(2016/18)/Issue7+TC2 0001220]: Add an API to query the name of a locale category of a locale object
A NOTE has been added to this issue. == https://austingroupbugs.net/view.php?id=1220 == Reported By:bhaible Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1220 Category: System Interfaces Type: Omission Severity: Editorial Priority: normal Status: New Name: Bruno Haible Organization: GNU User Reference: Section:--- Page Number:--- Line Number:--- Interp Status: --- Final Accepted Text: == Date Submitted: 2018-12-20 13:46 UTC Last Modified: 2020-10-26 10:03 UTC == Summary:Add an API to query the name of a locale category of a locale object == -- (0005063) geoffclare (manager) - 2020-10-26 10:03 https://austingroupbugs.net/view.php?id=1220#c5063 -- Re note 5062, note 5037 was discussed in the 8th October teleconference and the decision we made was that we would not modify https://austingroupbugs.net/view.php?id=1220#c5035 to add support for LC_ALL. In the 12th October teleconference we moved on to the backlog of other bugs because we had finished looking at the bugs relating to new APIs sponsored by The Open Group. To add support for LC_ALL we would need to specify how multiple locale names would be returned, and this would be complicated by the existence of additional non-standard categories. If an application wants to know the locale names for all of the categories, it can simply query them one at a time. Issue History Date ModifiedUsername FieldChange == 2018-12-20 13:46 bhaibleNew Issue 2018-12-20 13:46 bhaibleName => Bruno Haible 2018-12-20 13:46 bhaibleOrganization => GNU 2018-12-20 13:46 bhaibleSection => --- 2018-12-20 13:46 bhaiblePage Number => --- 2018-12-20 13:46 bhaibleLine Number => --- 2020-10-05 11:11 geoffclare Note Added: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 11:13 geoffclare Note Edited: 0005026 2020-10-05 15:45 bhaibleNote Added: 0005027 2020-10-05 17:57 shware_systems Note Added: 0005030 2020-10-05 17:58 shware_systems Note Edited: 0005030 2020-10-07 13:29 geoffclare Note Added: 0005035 2020-10-07 15:08 shware_systems Note Added: 0005037 2020-10-23 14:21 geoffclare Note Added: 0005059 2020-10-23 15:57 shware_systems Note Added: 0005062 2020-10-26 10:03 geoffclare Note Added: 0005063 ==
Re: printf (the utility) expected range of integer values
Robert Elz wrote, on 24 Oct 2020: > > Is there somewhere, anywhere, where it is possible to infer what > range of values printf (the utility, not the C library function) > is expected to handle? > > I can find nothing in the XCU 3.printf page, nor in XBD 5 (and also > not in XBD 12, which would be another plausible place). You missed XBD 12.1 list item 6? > XBD 14.limits.h gives the minimum allowed value for the maximum value > of an integer (2^31 - 1) (ie: requires at least 32 bit int), but I can > find nothing that says explicitly that that applies to printf the utility. LONG_MAX is the one that applies, via XCU 1.1.2.1 Arithmetic Precision and Operations: Integer variables and constants, including the values of operands and option-arguments, used by the standard utilities listed in this volume of POSIX.1-2017 shall be implemented as equivalent to the ISO C standard signed long data type > Further, since printf (the utility) is really just converting text > strings from one format to another, there's really no reason that there > needs to be any limit at all - there's no particular reason that integers > thousands of digits long couldn't be handled. The standard does say that > if overflow occurs, an error message, and non-zero exit status, must > occur, but it doesn't ever say that overflow must occur. XCU 1.1.2.1 implies there must be an upper limit, since signed long in ISO C is a fixed-width type. However, I suppose an implementation could get around that by claiming printf works as if implemented in a C programming environment where the number of hex digits in LONG_MAX is greater than ARG_MAX, and thus a too-large value could never be passed to (an external) printf. > Second question - if overflow does occur (at whatever point) what is the > value that must be printed (in addition to the error message) from a > numeric conversion. > [...] > what the standard says is: > > If an argument operand cannot be completely converted into an internal > value appropriate to the corresponding conversion specification, a > diagnostic message shall be written to standard error and the utility > shall not exit with a zero exit status, but shall continue processing > any remaining operands and shall write the value accumulated at the > time the error was detected to standard output. > > The question is, what is "the value accumulated at the time the error was > detected". That would obviously depend on internal implementation details. In particular, digits could be processed left-to-right or right-to-left, so the unused digits could be from either end. > What zsh does is: > > zsh $ printf '%d\n' 0xc000 > zsh: number truncated after 15 digits: c000 > 1152917106560335872 > > which makes some sense to me, I had been thinking this might be the > correct value, before I started testing to see what was produced. > That is, after the first 15 hex digits are consumed, that is the value > (0xc00 in decimal) and then when an attempt is made to > add one more zero, we detect the overflow, and so the value that had > been accumulated when the overflow was detected was 1152917106560335872 > (when printed via %d). > > The value "everybody" else prints, 9223372036854775807, is simply 2^63-1 > (the max possible value) which most likely was never actually encountered > during the conversion, but is just what strtoll() returns as its value. I think that's allowed, via the usual "as if" rule. An implementor could claim that printf is implemented as if the "accumulated" value is simply incremented until converting it to a hex string produces the same digits as were supplied, or the maximum representable accumulated value is reached. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
