https://austingroupbugs.net/issues_rss.php?project_id=0

1<?xml version="1.0" encoding="utf-8"?>
2<!--RSS generated by Flaimo.com RSS Builder [2026-09-25 19:25:26]-->
3<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"><channel><docs>https://austingroupbugs.net/</docs><link>https://austingroupbugs.net/</link><description><![CDATA[Austin Group Issue Tracker - Issues]]></description><title>Austin Group Issue Tracker - Issues</title><image><title>Austin Group Issue Tracker - Issues</title><url>https://austingroupbugs.net/images/AG_HEADER.png</url><link>https://austingroupbugs.net/</link><description><![CDATA[Austin Group Issue Tracker - Issues]]></description></image><language>en</language><category>All Projects</category><ttl>10</ttl><dc:language>en</dc:language><sy:updatePeriod>hourly</sy:updatePeriod><sy:updateFrequency>1</sy:updateFrequency><item><title>0001976: specify array variables and syntax</title><author></author><link>https://austingroupbugs.net/view.php?id=1976</link><description><![CDATA[POSIX sh specifies one array per function, the argument array&lt;br /&gt;
4&lt;br /&gt;
5many sh implementations support having array variables past the argument array&lt;br /&gt;
6&lt;br /&gt;
7due to posix shell specifying a syntax for the argument array, sh implementations&lt;br /&gt;
8with array extensions naturally landed on similar and compatible syntax&lt;br /&gt;
9&lt;br /&gt;
10mksh, ksh93, bash, zsh, osh, yash, all support the following syntax:&lt;br /&gt;
11	foo=(a b &quot;c d&quot; e)&lt;br /&gt;
12	foo+=(f g)&lt;br /&gt;
13	&quot;${foo[@]}&quot; # a b &quot;c d&quot; e f g&lt;br /&gt;
14	&quot;${foo[*]}&quot; # &quot;a b c d e f g&quot;&lt;br /&gt;
15	&quot;${foo[expr]}&quot; # indexed by expr, where expr is evaluated like $(( expr ))&lt;br /&gt;
16	&quot;${#foo[@]}&quot; # 6, the lenght of foo&lt;br /&gt;
17&lt;br /&gt;
18additionally, mksh, ksh, and zsh, support declaring arrays as such:&lt;br /&gt;
19	set -A name -- values&lt;br /&gt;
20&lt;br /&gt;
21notably ksh does not implement the name=(values) syntax, but has no other syntax&lt;br /&gt;
22that would conflict with it either&lt;br /&gt;
23&lt;br /&gt;
24ash and dash do not currently implement any sort of arrays, but also have&lt;br /&gt;
25no syntax that conflicts with the existing extensions]]></description><category>Shell and Utilities</category><pubDate>Thu, 24 Sep 2026 18:54:47 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1976</guid><comments>https://austingroupbugs.net/view.php?id=1976#bugnotes</comments></item><item><title>0002000: XSH 3/strfmon misses info and needs attention</title><author></author><link>https://austingroupbugs.net/view.php?id=2000</link><description><![CDATA[&lt;p&gt;&lt;br /&gt;
26In the sequel, I shall refer solely to &lt;i&gt;strfmon&lt;/i&gt;(), but everything applies equally to &lt;i&gt;strfmon_l&lt;/i&gt;().&lt;br /&gt;
27The mechanism by which the locale data is made available is not material to anything in this defect report.&lt;br /&gt;
28&lt;/p&gt;&lt;p&gt;&lt;br /&gt;
29The following defects are ordered in decreasing order of importance, as I see them, except with some related issues grouped adjacent to one another.&lt;br /&gt;
30All defects (except probably the last) should be corrected however.&lt;br /&gt;
31&lt;/p&gt;&lt;br /&gt;
32&lt;ol&gt;&lt;li&gt;&lt;br /&gt;
33When issue &lt;a href=&quot;https://austingroupbugs.net/view.php?id=1199&quot;&gt;0001199&lt;/a&gt; was fixed (the changes made as the result of that I generally agree with) one part of the original issue report seems to have been forgotten.&lt;br /&gt;
34It (&lt;a href=&quot;https://austingroupbugs.net/view.php?id=1199&quot;&gt;0001199&lt;/a&gt;) said:&lt;br /&gt;
35&lt;blockquote&gt;&lt;br /&gt;
36However, without a distinction between positive and negative values, and without a visible decimal separator, this behaviour is useless, or even dangerous &lt;br /&gt;
37&lt;/blockquote&gt;&lt;br /&gt;
38&lt;p&gt;&lt;br /&gt;
39The issue with positive/negative was (mostly) handled, the issue when there is no visible decimal separator was not, and needs to be.&lt;br /&gt;
40See issue &lt;a href=&quot;https://austingroupbugs.net/view.php?id=1199&quot;&gt;0001199&lt;/a&gt; for an example illustrating the problem.&lt;br /&gt;
41&lt;/p&gt;&lt;br /&gt;
42&lt;/li&gt;&lt;li&gt;&lt;br /&gt;
43&lt;p&gt;&lt;br /&gt;
44Following on from the previous, it is also unclear, even with the text as amended by issue &lt;a href=&quot;https://austingroupbugs.net/view.php?id=1199&quot;&gt;0001199&lt;/a&gt;,  what should be done when a locale defines non-empty strings to be used as the signs, but specifies the same string for both cases.&lt;br /&gt;
45This is effectively the same problem as issue &lt;a href=&quot;https://austingroupbugs.net/view.php?id=1199&quot;&gt;0001199&lt;/a&gt; dealt with, being unable to determine whether a value is positive, or negative, just in a different way.&lt;br /&gt;
46&lt;/p&gt;&lt;p&gt;&lt;br /&gt;
47Relevant to this, and what makes it different from the empty string case, is that the result might differ when the position of the sign string is different for positive and negative values.&lt;br /&gt;
48That is, it is not necessarily simply invalid to use the same non-empty string for both the positive and negative signs.&lt;br /&gt;
49&lt;/p&gt;&lt;br /&gt;
50&lt;/li&gt;&lt;li&gt;&lt;br /&gt;
51&lt;p&gt;&lt;br /&gt;
52It is not always clear in the specification when &lt;i&gt;character&lt;/i&gt; means &lt;b&gt;character&lt;/b&gt; and when it means &lt;b&gt;byte&lt;/b&gt; or perhaps &quot;character from a restricted character set&quot;, or something different entirely.&lt;br /&gt;
53&lt;/p&gt;&lt;p&gt;&lt;br /&gt;
54That the specification generally means &lt;b&gt;character&lt;/b&gt; is clear from line 69523:&lt;br /&gt;
55&lt;blockquote&gt;&lt;br /&gt;
56The format is a character string, beginning and ending in its initial state, if any, ...&lt;br /&gt;
57&lt;/blockquote&gt;&lt;br /&gt;
58which would make no sense if &lt;i&gt;character&lt;/i&gt; was being used as a synonym for the &lt;b&gt;C&lt;/b&gt; programming language &lt;b&gt;char&lt;/b&gt; data type, or simply a byte, or even a character from the Portable Character Set from the standard (XBD 6.1).&lt;br /&gt;
59Those kinds of characters have no state, hence no initial state to require.&lt;br /&gt;
60&lt;/p&gt;&lt;p&gt;&lt;br /&gt;
61This issue crops up in many places, the most obvious is in (line 69540):&lt;br /&gt;
62&lt;blockquote&gt;&lt;br /&gt;
63An '=' followed by a single character &lt;i&gt;f&lt;/i&gt; which is used as the numeric fill character.&lt;br /&gt;
64&lt;/blockquote&gt;&lt;br /&gt;
65The text (lines 69541-69542) attempts to add some meaning to this:&lt;br /&gt;
66&lt;blockquote&gt;&lt;br /&gt;
67In order to work with precision or width counts, the fill character shall be a single byte character; if not, the behavior is undefined.&lt;br /&gt;
68&lt;/blockquote&gt;&lt;br /&gt;
69But that makes no sense at all.&lt;br /&gt;
70To work with the precision and width counts, the fill character needs to occupy one column position in the output.&lt;br /&gt;
71That distinction has nothing at all to do with how many bytes are in the representation of the character.&lt;br /&gt;
72A single byte character, in some locales, might be zero-width or occupy multiple columns in the output, even in a constant width font.&lt;br /&gt;
73Obvious examples are the &lt;tab&gt; character, and ASCII control characters.&lt;br /&gt;
74A &lt;newline&gt; or &lt;carriage-return&gt; would have different, but related, issues.&lt;br /&gt;
75It is also unclear why the behaviour should be &lt;b&gt;undefined&lt;/b&gt; should the application not give a suitable character as the fill character value.&lt;br /&gt;
76That is a truly machiovellian punishment.&lt;br /&gt;
77Would it not be better to simply make it clear than in such cases the intended alignment might not be able to be achieved?&lt;br /&gt;
78That is, the implementation should just use whatever character is specified as &lt;i&gt;f&lt;/i&gt; when needed as the fill character, and if that character is not suitable for the purpose, the output will look odd, instead of nice.&lt;br /&gt;
79No calling &lt;i&gt;abort&lt;/i&gt;(), or removing all of the user's files, which &quot;undefined behaviour&quot; would permit.&lt;br /&gt;
80&lt;/p&gt;&lt;p&gt;&lt;br /&gt;
81A similar problem can be found at line 69577:&lt;br /&gt;
82&lt;blockquote&gt;&lt;br /&gt;
83A decimal digit string &lt;i&gt;w&lt;/i&gt; specifying a minimum field width in bytes&lt;br /&gt;
84&lt;/blockquote&gt;&lt;br /&gt;
85which also makes little sense, if one assumes as the specification seems to imply, at a minimum, that the objective is to be able to align output from multiple calls to &lt;i&gt;strfmon&lt;/i&gt;().&lt;br /&gt;
86What matters is the appearance of the final output, not how many bytes of encoded characters are needed to achieve that result.&lt;br /&gt;
87The number of bytes is, or should, only be relevant when determining whether the result fits within the &lt;i&gt;maxsize&lt;/i&gt; number of bytes available in the output buffer.&lt;br /&gt;
88Everything else should be using &lt;b&gt;character&lt;/b&gt;s, possibly constrained in some cases to be printing or graphic characters, and perhaps sometimes constrained by the widths of the characters concerned.&lt;br /&gt;
89This needs to be clear in the specification, with no mention of &lt;b&gt;bytes&lt;/b&gt; in any of the relevant places.&lt;br /&gt;
90&lt;p&gt;&lt;br /&gt;
91The same problem arises with everything else inserted into the resulting output string, including the &lt;i&gt;mon_decimal_point&lt;/i&gt; and the &lt;mon_thousands_sep&gt; strings.&lt;br /&gt;
92Lines 69592-69594 do explain the idea:&lt;br /&gt;
93&lt;blockquote&gt;&lt;br /&gt;
94To ensure alignment, any characters appearing before or after the number in the formatted output such as currency or sign symbols are padded as 

94necessary with <space> characters to make their positive and negative formats an equal length.<br />
95</blockquote><br />
96though that text does give rise to the immediately following defect.<br />
97</p><p><br />
98It should also be made clear what other constraints, if any, must be met for the output to be able to be nicely aligned.<br />
99The use of a monospace (constant width) font to display the result is an obvious one, without that achieving alignment requires much more complex mechanisms that simply counting characters, which is all that is available here.<br />
100But is it expected that all the values intended to be able to be aligned have neen formatted using the same locale, or is it intended that output from different locales be able to be intermixed, and remain aligned?<br />
101The answer to that question constrains what constraints should be placed upon what is permitted in locales for the <b>mon_decimal_point</b> (I have a fake locale, for testing purposes, which uses $'\u3002' as that character, and the font I use for my terminal sessions renders that character in 2 columns).<br />
102Is <i>strfmon</i>() expected to work with such a value?<br />
103It does, even to aligning (approximately) as intended, as the alighnment is primarily for the value to the left of the radix, which is unaffected by this.<br />
104But something similar might be used as the <b>mon_thousands_sep</b>.<br />
105Further, different locales might have different <b>mon_grouping</b> settings.<br />
106My fake locale uses "2;3;2;3;2" which is going to result in a different number of separators being inserted in some values than the more common "3".<br />
107As one call to <i>strfmon</i> has no way to communicate decisions to another, nor to predict what locale might be in use when the next call is made, it might seem necessary to constrain the alignment goal to apply only as long as the same locale is used for all relevant <i>strfmon</i> calls.<br />
108But that might also be too strict, perhaps as long as the locales used all use the same <b>mon_grouping</b>, and use as their <b>mon_decimal_point</b> and <b>mon_thousands_sep</b> strings which occupy the same number of columns as the equivalent setting in all other locales used in a sequence intended to align correctlty, that would be enough?<br />
109</p><p><br />
110Did no-one ever consider any of these questions?<br />
111</p><br />
112</li><li><br />
113<p><br />
114The text at lines 69592-69594:<br />
115<blockquote><br />
116To ensure alignment, any characters appearing before or after the number in the<br />
117formatted output such as currency or sign symbols are padded as necessary with<br />
118<space> characters to make their positive and negative formats an equal length.<br />
119</blockquote><br />
120concentrate entirely upon making the positive and negative output forms of equal length, but the text at lines 69582-69584:<br />
121<blockquote><br />
122This option can be used to keep the formatted output from multiple calls to the strfmon( ) function aligned in the same columns.<br />
123</blockquote><br />
124makes it clear that the aim that is implied by lines 69592-69594 is not sufficient to meet the expectations of the <i>strfmon</i> specification, and that more precision is required to meet the overall objective.<br />
125</p><p><br />
126That is, if for positive numbers, the sign follows the value, and for negative nnumbers the sign precedes the value, then, to keep the numeric parts of a positive and a negative value aligned, both of them must allocate space in the resulting<br />
127string for the possible negative sign before the value, and the possible positive sign following the value (when positive signs are being included), so that either of them might be used to occupy the sign value.<br />
128What's more, that is what implementations I have seen actually do.<br />
129Simply having the positive and negative formats being of equal length is not suffficient.<br />
130</p><p><br />
131It is also not stated anywhere, but clearly is intended (I hope), that the expected alignment is only achieved if the same format str

131ing is used for all the applicable calls to <i>strfmon</i>().<br />
132</p><br />
133</li><li><br />
134<p><br />
135A corollary to the previous two points, is that it should be made explicit that aligned values can only be expected to remain aligned when displayed or printed, if they are rendered in a constant width font, or at least one in which all characters are represented in a non-negative integer multiple of a fixed column width.<br />
136</p><br />
137</li><li><br />
138<p><br />
139The description of "grouping characters" (a term for which incidentally I can find no definition in the standard, though it is obvious that in this context it means the <b>mon_thousands_sep</b> characters inserted to perform the grouping function of monetary output values, which is a defined operation) and how they apply to the <b>Left Precision</b> given in lines 69589-69590 is one of the least useful specifications I think I have ever seen.<br />
140It states (lines 69589-69590):<br />
141<blockquote><br />
142If grouping has not been suppressed with the '^' flag, and it is defined for the current locale, grouping separators are inserted before the fill characters (if any) are added.<br />
143</blockquote><br />
144The pre-conditions are simple enough, but I would interpret the action as meaning that each "grouping separator" (another undefined term) inserted replaces one (or perhaps more) of the fill characters, which then fill in any remaining unused positions as specified in the previous paragraph (lines 69581-69588).<br />
145The subsequent sentence (line 69591), which ends the paragraph, about the inapplicability of grouping to fill characters, even if they are digits, is clear enough as it stands.<br />
146</p><p><br />
147But as illustrated by the examples (see lines 69640-69642 (or 69643-69645 or 69646-69648) in comparison with lines 69649-69651 which, apart from the use of a non-space fill character in the alternatives of the former, which is immaterial, show the same example, except the former has grouping enabled, and the latter with it suppressed), and from observing what is done by actual implementations, that is not what is intended at all.<br />
148Rather, the value given by the <b>Left Precision</b> "<i>n</i>" value, is to be increased by the maximum number of "grouping separators" which would be needed if a value to be formatted generates <i>n</i> (as specified) digits before the radix character (decimal-point) if any.<br />
149Then the value is formatted, and the number of "grouping separators" required for the actual value are inserted, and finally the increased value of <i>n</i> is used to fill any remaining unused positions with fill characters.<br />
150That is, the use of grouping can increase the number of fill characters to be used for a particular <i>value</i>, and the actual left precision width from what is in the conversion specification, but never decrease it, compared to when grouping is not used.<br />
151</p><p><br />
152How, an implementer, or an application writer, is intended to determine the intended behaviour from the written specification bamboozles me.<br />
153It needs rewriting.<br />
154</p><p><br />
155Note also, that though the <i>linux</i> manual page for this function attempts to make this clear, it is not a lot better:<br />
156<blockquote><br />
157Next, there may be a left precision of the form "#" followed by a decimal digit string.<br />
158If the number of digits left of the radix character is smaller than this, the representation is padded on the left with the numeric fill character.<br />
159Grouping characters are not counted in this field width.<br />
160</blockquote><br />
161That would make it seem as if the number of grouping characters inserted, or which might be inserted, has no effect on the padding inserted by the left precision, which is not correct either.<br />
162</p><br />
163</li><li><br />
164<p><br />
165The <b>ERRORS</b> section at lines 69628-69630 states the functions shall fail if:<br />
166<ul><br />
167<li>[EINVAL]<br />
168<blockquote><br />
169The '+' flag was included in a conversion specification and the locale's positive_sign and negative_sign values would both be returned by localeconv( ) as empty strings.<br />
170</blockquote></li><br />
171</ul><br />
172</p><p><br />
173The <b>APPLICATION USAGE</b> section, at lines 69672-69676:<br />
174<blockquote><br />
175The '+' flag should be used with care, because if the locale's positive_sign and negative_sign values are both empty strings, there is no way to distinguish negative from positive values with signs and therefore strfmon( ) fails. If the application has a preference for signs but parentheses are acceptable, it should try strfmon( ) with the '+' flag first, and if it fails with [EINVAL] then repeat the call without the '+' flag.<br />
176</blockquote><br />
177and the <b>RATIONALE</b> at lines 69678-69680:<br />
178<blockquote><br />
179The [EINVAL] error condition applies only when the '+' flag is used because this flag indicates that the application requires the use of signs, and if there are no signs in the locale data then this requirement cannot be satisfied.<br />
180</blockquote><br />
181together expand upon this intended unique use.<br />
182</p><p><br />
183While implementations are generally permitted to add error numbers, and to add meanings to errors the standard specifies, as specified by XSH 2.3 at lines 17831-17833:<br />
184<blockquote><br />
185Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or may contain extensions or limitations that prevent some errors from occurring.<br />
186</blockquote><br />
187that same section goes on to place a restriction upon this implementation freedom, at lines 17839-17841 (and following for more restrictions not relevant here):<br />
188<blockquote><br />
189Implementations may generate error numbers listed here under circumstances other than those described, if and only if all those error conditions can always be treated identically to the error conditions as described 

189in this volume of POSIX.1-2024.<br />
190</blockquote><br />
191</p><p><br />
192Taken together all of this implies, to me anyway, that the implementation may not generate <b>EINVAL</b> for any error other than the one listed, as an application would then be unable to ascertain that the problem was the '+' in the format string, and offer a different format for the locale in question in that case.<br />
193</p><p><br />
194The problem all this causes for the implementation, is just how it should deal with applications which fail to meet their <b>shall</b> obligations, for example the one at line 69529:<br />
195<blockquote><br />
196The application shall ensure that a conversion specification consists of the following sequence:<br />
197</blockquote><br />
198I appreciate that when an application fails to comply with its obligations, implementation behaviour is unspecified, or perhaps even undefined, and is certainly beyond the scope of the standard.<br />
199This however does not help the implementer, who must do something in such cases.<br />
200Further as it seems above, the implementer is prohibited from using the obvious <b>EINVAL</b> error code in such a situation.<br />
201Further, it does not help the application writer either, if some implementations simply ignore such issues and continue formatting as best they can, others return -1 and a seemingly random error code, and yet others simply call XSH 3 section 3/abort (pages 577-558).<br />
202</p><p><br />
203At the very least, the specification should offer some guidance in this situation, and probably rewrite the application usage and rationale, so as to no longer constrain <b>EINVAL</b> such that it cannot be used by the implementation for other issues.<br />
204</p><br />
205</li><li><br />
206<p><br />
207The standard offers no guidance on what should be done, should some of the data expected to be provided by the locale, is not defined there.<br />
208The <b>POSIX</b> locale is one which does not supply any.<br />
209Particularly after the resolution of issue <a href="https://austingroupbugs.net/view.php?id=1199">0001199</a>, some of this has<br />
210been dealt with, but not all.<br />
211This includes the lack of a (non-empty) <b>mon_decimal_point</b>.<br />
212There is also no discussion on what should be done if any of the specified strings are non-empty, but do not contain anything which produces a visible representation in the output.<br />
213</p><p><br />
214There should be.<br />
215</p><br />
216</li><li><br />
217<p><br />
218Returning to <b>APPLICATION USAGE</b> section, at lines 69672-69676:<br />
219<blockquote><br />
220The '+' flag should be used with care, because if the locale's positive_sign and negative_sign values are both empty strings, there is no way to distinguish negative from positive values with signs and therefore strfmon( ) fails. If the application has a preference for signs but parentheses are acceptable, it should try strfmon( ) with the '+' flag first, and if it fails with [EINVAL] then repeat the call without the '+' flag.<br />
221</blockquote><br />
222That suggests that simply omitting the '+' flag, will cause <i>stfrmon</i>() to use parentheses as the indicator for negative values.<br />
223That is not what the post-issue <a href="https://austingroupbugs.net/view.php?id=1199">0001199</a> standard causes to happen.<br />
224Instead, as stated on lines 69567-69571 when considering the case that<br />
225neither of the '+' nor '(' flags are included in the format:<br />
226<blockquote><br />
227If the style cannot be determined from these locale values because a value that needs to be used would be returned by localeconv() as {CHAR_MAX}, the style used shall be that specified for the '+' flag; if this would cause strfmon( ) to fail because the locale's positive_sign and negative_sign values would both be returned by localeconv( ) as empty strings, strfmon( ) shall behave as if the negative_sign value was the string "-".<br />
228</blockquote><br />
229In other words, unless the format specifies the '(' flag (in which case this section is never reached, and its <b>positive_sign</b> and <b>negative_sign</b> and sign placement values are all ignored), if the '+' flag is not given, and the locale's default is not to use parentheses to indicate negative values, then the resulting output would use the empty <b>positive_sign</b> if the <i>value</i> is non-negative, and use "-" instead of an empty <b>negative_sign</b> if the <i>value</i> is negative.<br />
230<p></p><br />
231This <b>APPLICATION USAGE</b> text needs to be rewritten to take that into account.<br />
232</p><br />
233</li><li><br />
234<p><br />
235At times the standard is too specific in what it specifies.<br />
236For example, at lines 69557-69558:<br />
237<blockquote><br />
238If a sign's placement cannot be determined from these locale values because a value that needs to be used would be returned by <i>localeconv</i>() as 0 or {CHAR_MAX}, ...<br />
239</blockquote><br />
240Why is it important what the issue is with the value?<br />
241</p><p><br />
242The range of values for the sign position are 0 to 4, with 0 not being useful for the situation being discussed in those lines, or {CHAR_MAX} to mean no value is supplied.<br />
243But what if the locale data specifies a value of 7?<br />
244That has no (currently) defined meaning, and hence is not useful for determining the placement of the sign, but it is not "returned by <i>localeconv</i>() as 0 or {CHAR_MAX}", so what is the implementation to do?<br />
245</p><p><br />
246This kind of over specification should be removed, it is not important why the sign placement cannot be determined from the locale values, just that it cannot.<br />
247Note that this is not just a fanciful, perhaps even imagined, impossible case.<br />
248A later version of the standard may add extra possible values to any of the fields for which a set of numeric designated choices are provided, and an older implenentation (an instance of <i>stfrmon</i> compiled into an existing applicaion for example) may encounter a previously invalid value, and needs to know how to handle that case.<br />
249This is not an instance where "behaviour is unspecified"

249 (or even "undefined") is an acceptable outcome.<br />
250The standard must be permitted to evolve without invalidating existing applications.<br />
251</p><br />
252</li><li><br />
253<p><br />
254The <b>EXAMPLES</b> section, page 2132 (lines 69632-69670) assumes the existence of "a locale for the US" and, to make sense of the example output, what that locale must contain.<br />
255I can find no justification in the standard to assume that such a locale exists anywhere.<br />
256I certainly believe that most readers would understand <b>USD</b> as the international currency symbol for the United States of America, and <b>$</b> as its national currency symbol, and probably that its <b>frac_digits</b> and <b>int_frac_digits</b> would usually both be two.<br />
257I am not sure however that using a "<b>-</b>" to indicate negative values, and nothing for positive ones, rather than enclosing negative values in parentheses, or use of <b>CR</b> for positive and <b>DB</b> for negative, is how such a locale would be defined.<br />
258Nor would I necessarily expect the sign, if used, to precede the currency symbol, rather than follow it.<br />
259</p><p><br />
260If some fictional locale is to be used for examples, regardless of whether that locale might be an actual locale on some system used by one or more of the actual writers of the text, then at least as much of it as is needed to understand the examples should be presented in the specification.<br />
261</p><p><br />
262Further, there should certainly be examples given where the <b>POSIX</b> (aka <b>C</b>) locale, the only one the standard actually specifies, is used.<br />
263Had there been, some of the problems this specification had before issue <a href="https://austingroupbugs.net/view.php?id=1199">0001199</a> rectified them, and some of the problems it still has, might have been recognised and corrected much sooner than this.<br />
264</p><br />
265</li><li><br />
266<p><br />
267The <b>DESCRIPTION</b> at lines 69524-69526 contains:<br />
268<blockquote><br />
269<b>...</b>, and conversion specifications, each of which shall result in the fetching of zero or more arguments which are converted and formatted.<br />
270</blockquote><br />
271"Zero or more" ?<br />
272<br /><br />
273<br /><br />
274The zero case is obviously for the <b>%%</b> format conversion specification (which I personally would not treat as a conversion specification at all, but as an escaping mechanism, but that isn't the point here).<br />
275<br /><br />
276<br /><br />
277But "or more" ??<br />
278<br /><br />
279<br /><br />
280One is certainly more than zero, and one (exactly) is what every other format conversion requires.<br />
281Why not just say "zero or one", and not leave the reader wondering when more than one might be required?<br />
282Of course, if there is some hidden intent to allow indirect specification of the field width, the left precision, or the right precision, or some or all of those, in the way that the printf family of functions permit, which would perhaps be a useful addition, though not supported by any implementation of which I am aware, then the "or more" would be justified.<br />
283</p><br />
284</li><li><br />
285<p><br />
286In the same paragraph as the previous defect (lines 69524-69526) the text elided at the beginning of the text quoted previously is:<br />
287<blockquote><br />
288The format is a character string, beginning and ending in its initial state, if any, that contains two types of objects: <i>plain characters</i>, which are simply copied to the output stream, <b>...</b><br />
289</blockquote><br />

290but there is no definition anywhere of what is a <i>plain character</i>.<br />
291The intent is obvious, but standards should not rely upon readers being able to deduce from what appears to be obvious, they should be explicit.<br />
292</p><br />
293</li><li><br />
294<p><br />
295The locale specification (XBD 7) and the specification of <i>strfmon</i> seem to lack the ability to format currency amounts in the (old style to be sure) formats previously used in the UK, and other countries including AU and NZ.<br />
296That is, the Lsd format, as in £10/- or £9-19-11 and similar constructions.<br />
297There may be other formats in use, or previously in use, which are similarly neglected.<br />
298</p><p><br />
299There is also no way to specify that other characters, rather than '(' and ')' be used to surround values, further it should be possible to have different characters surrounding positive and negative values - the <b>positive_sign</b> and <b>negative_sign</b> settings cannot be used for this, as only one of them is ever used for any particular value, and whichever that is is only ever used once.<br />
300</p><p><br />
301These issues should be fixed, but this is not the place to do it.<br />
302Thus I will not offer potential solutions - the issue is here just so it is clear that the problems are known, and cannot at some future time be dismissed with "We didn't ever consider those possibilities."<br />
303</p><br />
304&lt;/li&gt;&lt;/ol&gt;]]></description><category>System Interfaces</category><pubDate>Thu, 17 Sep 2026 19:28:07 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=2000</guid><comments>https://austingroupbugs.net/view.php?id=2000#bugnotes</comments></item><item><title>0001992: Add getexepath() to retrieve the absolute pathname of the current process executable image.</title><author></author><link>https://austingroupbugs.net/view.php?id=1992</link><description><![CDATA[There is currently no standardized, portable mechanism in POSIX to retrieve the absolute pathname of the executable file currently executing the calling process. Runtimes, language interpreters, and asset loaders must resort to highly unportable, platform-specific mechanisms. &lt;br /&gt;
305&lt;br /&gt;
306- Linux relies on parsing the &quot;/proc/self/exe&quot; symlink or using `getauxval(AT_EXECFN)`.&lt;br /&gt;
307- FreeBSD and NetBSD use a sysctl interface via KERN_PROC_PATHNAME.&lt;br /&gt;
308- SunOS implements getexecname().&lt;br /&gt;
309- macOS implements a non-POSIX _NSGetExecutablePath() function.&lt;br /&gt;
310&lt;br /&gt;
311Others like OpenBSD force us to rely on argv[0] and (if the process didn't start with an absolute path) scanning the PATH environment variable, which is fundamentally unsafe and unreliable (someone else in the PATH with the same name appearing early is picked up). Furthermore, the parent process can easily manipulate or empty argv and envp during an execve() call, leaving the child completely unable to safely determine its own physical location. &lt;br /&gt;
312&lt;br /&gt;
313Adding a native, safe API to POSIX eliminates immense cross-platform boilerplate across programming frameworks and toolchains that require explicit binary path auditing.]]></description><category>System Interfaces</category><pubDate>Tue, 15 Sep 2026 04:03:15 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1992</guid><comments>https://austingroupbugs.net/view.php?id=1992#bugnotes</comments></item><item><title>0001616: Standardize mktemp utility</title><author></author><link>https://austingroupbugs.net/view.php?id=1616</link><description><![CDATA[The current standard has no reliable and convenient utility to create temporary file or directory, despite that low-level interfaces, mkstemp/mkdtemp, are available for this use case. The mktemp(1) utility is a perfect candidate to fill this gap. Its interface is fairly simple and mostly consistent across various implementations, however not without some differences. I evaluated GNU, LSB, NetBSD, FreeBSD, OpenBSD, Illumos, Solaris, sbase, toybox, busybox implementations and here is what I found:&lt;br /&gt;
314&lt;br /&gt;
315- FreeBSD, NetBSD accept multiple templates. Others do not.&lt;br /&gt;
316- FreeBSD does not specify -p option. Others do.&lt;br /&gt;
317- LSB does not specify -d and -p options. Others do.&lt;br /&gt;
318- FreeBSD, NetBSD accept parameter for -t option. Others do not.&lt;br /&gt;
319- FreeBSD, NetBSD use -t option to specify prefix. Others use it to explicitly tell mktemp to create temporary file in temporary directory rather than 

319in current directory.<br />
320- All have different default value for template.<br />
321- All have different requirements regarding how many Xs template should contain, but it seems they all accept six Xs.<br />
322- sbase, Illumos, Solaris override -p parameter with TMPDIR value if it is set. Others do not.<br />
323- GNU overrides -p parameter with TMPDIR value or /tmp if parameter is empty string. Others do not.<br />
324- OpenBSD, Illumos, Solaris(not sure), toybox do not allow '/' in template if -p option is passed. Others do.<br />
325<br />
326Given that, I think mktemp interface is not completely lost and below is my attempt to make it portable.]]></description><category>Shell and Utilities</category><pubDate>Mon, 14 Sep 2026 16:55:58 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1616</guid><comments>https://austingroupbugs.net/view.php?id=1616#bugnotes</comments></item><item><title>0001997: cp,mv,pax should not need to diagnose timestamp downresing</title><author></author><link>https://austingroupbugs.net/view.php?id=1997</link><description><![CDATA[When the command ‘mv /a/SOURCE DEST’ crosses file system boundaries, the resulting file DEST can have a timestamp with less low-order information as described by futimens (POSIX.1-2024 page 1075 lines 36821–36822). For example, the source file’s timestamp might be 1786900895.478636836 but the destinations might be on a FAT32 filesystem so its timestamp might be only 1786900895.47, as FAT32 has only 10 ms resolution.&lt;br /&gt;
327&lt;br /&gt;
328This topic recently came up in a bug report for GNU mv &lt;&lt;a href=&quot;https://bugs.gnu.org/13601#40&gt;&quot; rel=&quot;noopener&quot;&gt;https://bugs.gnu.org/13601#40&gt;.&lt;/a&gt; One commenter there said that this loss of information triggers the clause for mv (page 3199 lines 108114–108115) saying “If the duplication of the file characteristics fails for any reason, mv shall write a diagnostic message to standard error” which means a diagnostic is required.&lt;br /&gt;
329&lt;br /&gt;
330GNU mv, and I expect all other mv implementations, does not do that. Instead, it uses futimens or utimensat to set DEST’s timestamps, and if that succeeds it does not issue a diagnostic. Checking whether DEST’s timestamp lost low-order info would require another system call, and I don’t know of any mv implementation that does so.&lt;br /&gt;
331&lt;br /&gt;
332A clarification is needed here for the phrase “duplication of the file characteristic fails for any reason”. Does the phrase mean that (a) a system call like futimens failed, or does it mean that (b) the destination’s characteristics disagree, even slightly, from the source’s? Although implementations have chosen (a) POSIX could be read as requiring (b).&lt;br /&gt;
333&lt;br /&gt;
334If an implementation wanted to implement (b), for efficiency it would be helpful if utimensat acquired an additional flag to cause the system call to fail if the timestamp is downresed. However, that would be a separate topic from this bug report, and I know of no platform that has such a flag so at this point it would be pure invention on the POSIX committee’s part.&lt;br /&gt;
335&lt;br /&gt;
336In the DESIRED ACTION I have attempted to word things so that an implementation can do either (a) or (b). (b) is allowed because an implementation can always issue a diagnostic whenever it likes, so long as it does not change the exit status.]]></description><category>Shell and Utilities</category><pubDate>Mon, 14 Sep 2026 16:06:46 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1997</guid><comments>https://austingroupbugs.net/view.php?id=1997#bugnotes</comments></item><item><title>0001998: Where should MANTIS issues be submitted?</title><author></author><link>https://austingroupbugs.net/view.php?id=1998</link><description><![CDATA[I just spent an hour or two filling in an issue report (a long one)&lt;br /&gt;
337only for when I submitted it to be told there was an invalid security&lt;br /&gt;
338token, either I had submitted twice (no) or the session had timed&lt;br /&gt;
339out (possible, given it had taken a LONG time to get all the details&lt;br /&gt;
340page numbers, line numbers, ... inserted properly.    And to decide&lt;br /&gt;
341what exactly I needed to report.&lt;br /&gt;
342&lt;br /&gt;
343It told me to press the back button on my browser.   I did.   All the&lt;br /&gt;
344text I had entered was gone (in previous interfaces that didn't happen,&lt;br /&gt;
345I could create a new report, and cut and paste everything from the old&lt;br /&gt;
346to the new, which would take much less time, and no timeout would&lt;br /&gt;
347occur - it has been ages since my last interaction with this, I had forgotten&lt;br /&gt;
348this issue.]]></description><category>Base Definitions and Headers</category><pubDate>Mon, 14 Sep 2026 15:17:10 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1998</guid><comments>https://austingroupbugs.net/view.php?id=1998#bugnotes</comments></item><item><title>0001996: Add SIGEV_SIGNAL_THREAD to allow more efficient handling of sigevent-using functions.</title><author></author><link>https://austingroupbugs.net/view.php?id=1996</link><description><![CDATA[Currently, there are only two notification mechanisms for use with sigevent: SIGEV_SIGNAL and SIGEV_THREAD. Both of these methods have issue preventing their use, and so a new notification should be added.&lt;br /&gt;
349&lt;br /&gt;
350SIGEV_THREAD typically spawns a new thread on each event, which degrades performance to the point that it defeats the purpose of using such a notification; performing the corresponding blocking opperation in a new thread would typically be both faster and more convenient. SIGEV_SIGNAL requires use of a signal handler; as signal handlers are shared between all threads in a process, this makes it unsuitable for use in a library.&lt;br /&gt;
351&lt;br /&gt;
352To resolve this, several platforms have added mechanisms to direct the signal to a specific thread. However, this mechanism is not standardised, which imhibits its use. This proposal serves to standardise it.]]></description><category>System Interfaces</category><pubDate>Sun, 13 Sep 2026 22:12:31 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1996</guid><comments>https://austingroupbugs.net/view.php?id=1996#bugnotes</comments></item><item><title>0001994: exp() assumes default rounding</title><author></author><link>https://austingroupbugs.net/view.php?id=1994</link><description><![CDATA[If the correct value would cause overflow, a range error shall occur&lt;br /&gt;
353and exp(), expf(), and expl() shall return the value of the macro&lt;br /&gt;
354HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively.]]></description><category>System Interfaces</category><pubDate>Fri, 11 Sep 2026 23:39:49 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1994</guid><comments>https://austingroupbugs.net/view.php?id=1994#bugnotes</comments></item><item><title>0001999: Session timeouts too short</title><author></author><link>https://austingroupbugs.net/view.php?id=1999</link><description><![CDATA[I just spent an hour or two filling in an issue report (a long one)&lt;br /&gt;

355only for when I submitted it to be told there was an invalid security<br />
356token, either I had submitted twice (no) or the session had timed<br />
357out (possible, given it had taken a LONG time to get all the details<br />
358page numbers, line numbers, ... inserted properly. And to decide<br />
359what exactly I needed to report.<br />
360<br />
361It told me to press the back button on my browser. I did. All the<br />
362text I had entered was gone (in previous interfaces that didn't happen,<br />
363I could create a new report, and cut and paste everything from the old<br />
364to the new, which would take much less time, and no timeout would<br />
365occur - it has been ages since my last interaction with this, I had forgotten<br />
366this issue.]]></description><category>Aardvark 2025</category><pubDate>Wed, 02 Sep 2026 15:51:29 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1999</guid><comments>https://austingroupbugs.net/view.php?id=1999#bugnotes</comments></item><item><title>0001995: Add SHM_ANON to shm_open()</title><author></author><link>https://austingroupbugs.net/view.php?id=1995</link><description><![CDATA[SHM_ANON can be used to create an unnamed shared memory object, which will be automatically destroyed when last reference to it is removed. It is mainly useful for avoiding potential conflicts with already existing shared memory objects, hiding the object from other processes and making the use of shm_unlink unnecessary since the object has no name.&lt;br /&gt;
367&lt;br /&gt;
368This extension is known to be implemented at least by QNX and FreeBSD. Linux provides similar memfd_create() interface, which can be used to mimic SHM_ANON.&lt;br /&gt;
369&lt;br /&gt;
370See also: &lt;a href=&quot;https://github.com/lassik/shm_open_anon&quot; rel=&quot;noopener&quot;&gt;https://github.com/lassik/shm_open_anon&lt;/a&gt;]]></description><category>System Interfaces</category><pubDate>Mon, 10 Aug 2026 22:10:11 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1995</guid><comments>https://austingroupbugs.net/view.php?id=1995#bugnotes</comments></item><item><title>0001949: Restore the traditional realloc(3) specification</title><author></author><link>https://austingroupbugs.net/view.php?id=1949</link><description><![CDATA[Name&lt;br /&gt;
371	alx-p0001r0 - Restore the traditional realloc(3) specification&lt;br /&gt;
372&lt;br /&gt;
373Category&lt;br /&gt;
374	Remove UB.&lt;br /&gt;
375&lt;br /&gt;
376[ADMINISTRATOR EDIT: removed personal email addresses from Description]&lt;br /&gt;
377&lt;br /&gt;
378History&lt;br /&gt;
379	&lt;&lt;a href=&quot;https://www.alejandro-colomar.es/src/alx/alx/std/posix/alx-p0001.git/&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.alejandro-colomar.es/src/alx/alx/std/posix/alx-p0001.git/&gt;&lt;/a&gt;&lt;br /&gt;
380&lt;br /&gt;
381	alx-0029r0 (2025-06-17):&lt;br /&gt;
382	-  Initial draft.&lt;br /&gt;
383&lt;br /&gt;
384	alx-0029r1 (2025-06-20):&lt;br /&gt;
385	-  Full rewrite after the recent glibc discussion.&lt;br /&gt;
386&lt;br /&gt;
387	alx-0029r2 (2025-06-21):&lt;br /&gt;
388	-  Remove CC.  Add CC.&lt;br /&gt;
389	-  wfix.&lt;br /&gt;
390	-  Drop quote.&lt;br /&gt;
391	-  Add a few more principles&lt;br /&gt;
392	-  Clarify why ENOMEM is used in this proposal, and make it&lt;br /&gt;
393	   optional.&lt;br /&gt;
394	-  Mention exceptional leak in code checking (size != 0).&lt;br /&gt;
395	-  Clarify that part of the description of realloc can be&lt;br /&gt;
396	   editorially removed after this change.&lt;br /&gt;
397&lt;br /&gt;
398	alx-0029r3 (2025-06-23):&lt;br /&gt;
399	-  Fix diff missing line.&lt;br /&gt;
400	-  Remove ENOMEM from the proposal.&lt;br /&gt;
401	-  Clarify that ENOMEM should be retained by platforms already&lt;br /&gt;
402	   using it.&lt;br /&gt;
403	-  Add mention that LLVM's address sanitizer will catch the leak&lt;br /&gt;
404	   mentioned in r2.&lt;br /&gt;
405	-  Add links to real bugs (including an RCE bug).&lt;br /&gt;
406&lt;br /&gt;
407	alx-0029r4 (2025-06-24):&lt;br /&gt;
408	-  Use a better link for the Whatsapp RCE.&lt;br /&gt;
409	-  s/Description/Rationale/&lt;br /&gt;
410	-  wfix&lt;br /&gt;
411	-  Mention that glibc &lt;2.1.1 had the BSD behavior.&lt;br /&gt;
412	-  Add footnote that realloc(3) may fail while shrinking.&lt;br /&gt;
413&lt;br /&gt;
414	alx-0029r5 (2025-06-26):&lt;br /&gt;
415	-  It was glibc 2.1.1 that broke it, not glibc 2.2.&lt;br /&gt;
416	-  wfix&lt;br /&gt;
417	-  Mention in the footnote that the pointer may change.&lt;br /&gt;
418	-  Document why not go the other way around.  It was explained&lt;br /&gt;
419	   several times during discussion, but people keep suggesting&lt;br /&gt;
420	   it.&lt;br /&gt;
421&lt;br /&gt;
422	alx-0029r6 (2025-06-27; n3621):&lt;br /&gt;
423	-  Clarify that the paragraph about what happens when the size&lt;br /&gt;
424	   is zero refers to when the total size is zero (for calloc(3)&lt;br /&gt;
425	   that is nmemb*size).&lt;br /&gt;
426	-  s/Unix V7/V7 Unix/&lt;br /&gt;
427	-  tfix.&lt;br /&gt;
428	-  wfix.&lt;br /&gt;
429&lt;br /&gt;
430	Brno meeting (2025-08-27):&lt;br /&gt;
431	-  9/13/6&lt;br /&gt;
432	-  Along the lines: 21/1/5&lt;br /&gt;
433	-  People recognized in the dinner after the meeting, and in the&lt;br /&gt;
434	   reflector, and in corridor discussions, that they hadn't&lt;br /&gt;
435	   understood the paper, and that it was more well thought than&lt;br /&gt;
436	   they initially thought.  They would change their vote to be&lt;br /&gt;
437	   in favour with this proposal.&lt;br /&gt;
438&lt;br /&gt;
439	alx-0029r7 (2025-09-21):&lt;br /&gt;
440	-  Add link.&lt;br /&gt;
441&lt;br /&gt;
442	alx-p0001r0 (2025-09-21):&lt;br /&gt;
443	-  Fork POSIX proposal from ISO C proposal.&lt;br /&gt;
444&lt;br /&gt;
445See also&lt;br /&gt;
446	&lt;&lt;a href=&quot;https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0069.git/&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.alejandro-colomar.es/src/alx/alx/wg14/alx-0069.git/&gt;&lt;/a&gt;&lt;br /&gt;
447	&lt;&lt;a href=&quot;https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html&gt;&quot; rel=&quot;noopener&quot;&gt;https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html&gt;&lt;/a&gt;&lt;br /&gt;
448	&lt;&lt;a href=&quot;https://sourceware.org/pipermail/libc-alpha/1999-April/000956.html&gt;&quot; rel=&quot;noopener&quot;&gt;https://sourceware.org/pipermail/libc-alpha/1999-April/000956.html&gt;&lt;/a&gt;&lt;br /&gt;
449	&lt;&lt;a href=&quot;https://inbox.sourceware.org/libc-alpha/nbyurzcgzgd5rdybbi4no2kw5grrc32k63svf7oq73nfcbus5r@77gry66kpqfr/&gt;&quot; rel=&quot;noopener&quot;&gt;https://inbox.sourceware.org/libc-alpha/nbyurzcgzgd5rdybbi4no2kw5grrc32k63svf7oq73nfcbus5r@77gry66kpqfr/&gt;&lt;/a&gt;&lt;br /&gt;
450	&lt;&lt;a href=&quot;https://inbox.sourceware.org/libc-alpha/[email protected]/T/#u&gt;&quot; rel=&quot;noopener&quot;&gt;https://inbox.sourceware.org/libc-alpha/[email protected]/T/#u&gt;&lt;/a&gt;&lt;br /&gt;
451	&lt;&lt;a href=&quot;https://inbox.sourceware.org/libc-alpha/qukfe5yxycbl5v7ooskvqdnm3au3orohbx4babfltegi47iyly@or6dgf7akeqv/T/#u&gt;&quot; rel=&quot;noopener&quot;&gt;https://inbox.sourceware.org/libc-alpha/qukfe5yxycbl5v7ooskvqdnm3au3orohbx4babfltegi47iyly@or6dgf7akeqv/T/#u&gt;&lt;/a&gt;&lt;br /&gt;
452	&lt;&lt;a href=&quot;https://github.com/bminor/glibc/commit/7c2b945e1fd64e0a5a4dbd6ae6592a7314dcd4b5&gt;&quot; rel=&quot;noopener&quot;&gt;https://github.com/bminor/glibc/commit/7c2b945e1fd64e0a5a4dbd6ae6592a7314dcd4b5&gt;&lt;/a&gt;&lt;br /&gt;
453	&lt;&lt;a href=&quot;https://github.com/llvm/llvm-project/issues/113065&gt;&quot; rel=&quot;noopener&quot;&gt;https://github.com/llvm/llvm-project/issues/113065&gt;&lt;/a&gt;&lt;br /&gt;
454	&lt;&lt;a href=&quot;https://www.austingroupbugs.net/view.php?id=400&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.austingroupbugs.net/view.php?id=400&gt;&lt;/a&gt;&lt;br /&gt;
455	&lt;&lt;a href=&quot;https://www.austingroupbugs.net/view.php?id=526&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.austingroupbugs.net/view.php?id=526&gt;&lt;/a&gt;&lt;br /&gt;
456	&lt;&lt;a href=&quot;https://www.austingroupbugs.net/view.php?id=688&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.austingroupbugs.net/view.php?id=688&gt;&lt;/a&gt;&lt;br /&gt;
457	&lt;&lt;a href=&quot;https://sourceware.org/bugzilla/show_bug.cgi?id=12547&gt;&quot; rel=&quot;noopener&quot;&gt;https://sourceware.org/bugzilla/show_bug.cgi?id=12547&gt;&lt;/a&gt;&lt;br /&gt;
458	&lt;&lt;a href=&quot;https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm&gt;&lt;/a&gt;&lt;br /&gt;
459	&lt;&lt;a href=&quot;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm&gt;&lt;/a&gt;&lt;br /&gt;
460	&lt;&lt;a href=&quot;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm&gt;&lt;/a&gt;&lt;br /&gt;
461	&lt;&lt;a href=&quot;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf&gt;&quot; rel=&quot;noopener&quot;&gt;https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf&gt;&lt;/a&gt;&lt;br /&gt;
462	&lt;&lt;a href=&quot;https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/realloc.html&gt;&quot; rel=&quot;noopener&quot;&gt;https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/realloc.html&gt;&lt;/a&gt;&lt;br /&gt;
463	&lt;&lt;a href=&quot;https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/functions/realloc.html&gt;&quot; rel=&quot;noopener&quot;&gt;https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/functions/realloc.html&gt;&lt;/a&gt;&lt;br /&gt;
464	&lt;&lt;a href=&quot;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744&gt;&quot; rel=&quot;noopener&quot;&gt;https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744&gt;&lt;/a&gt;&lt;br /&gt;
465	&lt;&lt;a href=&quot;https://lore.kernel.org/lkml/[email protected]/&gt;&quot; rel=&quot;noopener&quot;&gt;https://lore.kernel.org/lkml/[email protected]/&gt;&lt;/a&gt;&lt;br /&gt;
466	&lt;&lt;a href=&quot;https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/&gt;&quot; rel=&quot;noopener&quot;&gt;https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/&gt;&lt;/a&gt;&lt;br /&gt;
467	&lt;&lt;a href=&quot;https://gbhackers.com/whatsapp-double-free-vulnerability/&gt;&quot; rel=&quot;noopener&quot;&gt;https://gbhackers.com/whatsapp-double-free-vulnerability/&gt;&lt;/a&gt;&lt;br /&gt;
468&lt;br /&gt;
469Rationale&lt;br /&gt;
470	The specification of realloc(3) has been problematic since the&lt;br /&gt;
471	very first standards, even before ISO C.  The wording has&lt;br /&gt;

472	changed significantly, trying to forcedly permit implementations<br />
473	to return a null pointer when the requested size is zero.  This<br />
474	originated from the intent of banning zero-sized objects from<br />
475	the language in C89, but that never worked well in<br />
476	retrospective, as we can see from the fallout.<br />
477<br />
478	None of the specifications have been good, and C23 finally gave<br />
479	up and made it undefined behavior.<br />
480<br />
481	The problem is not only theoretical.  Programmers don't know how<br />
482	to use realloc(3) correctly, and have written weird code in<br />
483	their attempts.  This has resulted in a lot of non-sensical code<br />
484	in configure scripts[1], and even bugs in actual programs[2].<br />
485<br />
486	[1] <<a href="https://codesearch.debian.net/search?q=%5Cbrealloc%5B+%5Ct%5D*%5B%28%5D%5B%5E%2C%5D*%2C%5B+%5Ct%5D0%5B%29%5D&literal=0>" rel="noopener">https://codesearch.debian.net/search?q=%5Cbrealloc%5B+%5Ct%5D*%5B%28%5D%5B%5E%2C%5D*%2C%5B+%5Ct%5D0%5B%29%5D&literal=0></a><br />
487	[2] <<a href="https://lore.kernel.org/lkml/[email protected]/>" rel="noopener">https://lore.kernel.org/lkml/[email protected]/></a><br />
488<br />
489	In some cases, this non-sensical code has resulted in RCEs[3].<br />
490<br />
491	[3] <<a href="https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/>" rel="noopener">https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/></a><br />
492<br />
493	However, this doesn't need to be like that.  The traditional<br />
494	implementation of realloc(3), present in V7 Unix, inherited by<br />
495	the BSDs, and currently available in a range of systems,<br />
496	including musl libc, doesn't have any issues regarding zero-size<br />
497	allocations.  glibc --which uses an independent implementation<br />
498	rather than a Unix derivative-- also had this behavior<br />
499	originally; it changed to the current behavior in 1999<br />
500	(glibc 2.1.1), only for compatibility with C89, even though<br />
501	ironically C99 was released soon after and removed the text that<br />
502	glibc was trying to comply with, and introduced some new text<br />
503	that was very confusing, and one of its interpretations would<br />
504	make the new glibc behavior non-conforming.<br />
505<br />
506	Code written for platforms returning a null pointer can be<br />
507	migrated to platforms returning non-null, without significant<br />
508	issues.<br />
509<br />
510	There are two kinds of code that call realloc(p,0).  One<br />
511	hard-codes the 0, and is used as a replacement of free(p).  This<br />
512	code ignores the return value, since it's unimportant.  This<br />
513	code currently produces a leak of 0 bytes plus associated<br />
514	metadata on platforms such as musl libc, where it returns a<br />
515	non-null pointer.  However, assuming that there are programs<br />
516	written with the knowledge that they won't ever be run on such<br />
517	platforms, we should take care of that, and make sure they don't<br />
518	leak.  A way of accomplishing this would be to recommend<br />
519	implementations to issue a diagnostic when realloc(3) is called<br />
520	with a hardcoded zero.  This is only an informal recommendation<br />
521	made by this proposal, as this is a matter of QoI, and the<br />
522	standard shouldn't say anything about it.  This would prevent<br />
523	this class of minor leaks.<br />
524<br />
525	Moreover, in glibc, realloc(p,0) may return non-null, in the<br />
526	case where p is NULL, so code must already take that into<br />
527	account, and thus code that simply takes realloc(p,0) as a<br />
528	synonym of free(p) is already leaky, as free(NULL) is a no-op,<br />
529	but realloc(NULL,0) allocates 0 bytes.<br />
530<br />
531	The other kind of code is in algorithms that realloc(3) an<br />
532	arbitrary size, which might eventually be zero.  This gets more<br />
533	complex.<br />
534<br />
535	Here's the code that should be written for AIX or glibc:<br />
536<br />
537		errno = 0;<br />
538		new = realloc(old, size);<br />
539		if (new == NULL) {<br />
540			if (errno == ENOMEM)<br />
541				free(old);<br />
542			goto fail;<br />
543		}<br />
544		...<br />
545		free(new);<br />
546<br />
547	Failing to check for ENOMEM in these platforms before freeing<br />
548	the old pointer would result in a double-free.  If the program<br />
549	decides to continue using the old pointer instead of freeing it,<br />
550	it would result in a use-after-free.<br />
551<br />
552	In the platforms where realloc(p,0) returns non-null, such as<br />
553	the BSDs or musl libc, it is simpler to handle it:<br />
554<br />
555		new = realloc(old, size);<br />

556		if (new == NULL) {  // errno is ENOMEM<br />
557			free(old);<br />
558			goto fail;<br />
559		}<br />
560		...<br />
561		free(new);<br />
562<br />
563	Whenever the result is a null pointer, these platforms are<br />
564	reporting an ENOMEM error, and thus it is superfluous to check<br />
565	errno there.<br />
566<br />
567	Most code is written in this way, even if run on platforms<br />
568	returning a null pointer.  This is because most programmers are<br />
569	just unaware of this problem.  Part of the reason is also that<br />
570	returning a non-null pointer with zero bytes is the natural<br />
571	extension of the behavior, which is what programmers intuitively<br />
572	expect from libc; that is, if realloc(p,3) allocates 3 bytes,<br />
573	r(p,2) allocates two bytes, and r(p,1) allocates one byte, it is<br />
574	natural by induction to expect that r(p,0) will allocate zero<br />
575	bytes.  Most algorithms naturally extend to 0 just fine, and<br />
576	special casing 0 is artificial.<br />
577<br />
578	If the realloc(3) specification were changed to require that<br />
579	realloc(p,0) returns non-null on success, and that realloc(p,0)<br />
580	only fails when out-of-memory (and assuming the implementations<br />
581	will continue setting errno to ENOMEM), then code written for<br />
582	AIX or glibc would continue working just fine, since the errno<br />
583	check would be redundant with the null check.  Simply, the<br />
584	conditional (errno == ENOMEM) would always be true when<br />
585	(new == NULL).<br />
586<br />
587	Then, there are non-POSIX platforms that don't set ENOMEM.  In<br />
588	those platforms, code might do this:<br />
589<br />
590		new = realloc(old, size);<br />
591		if (new == NULL) {<br />
592			if (size != 0)<br />
593				free(old);<br />
594			goto fail;<br />
595		}<br />
596		...<br />
597		free(new);<br />
598<br />
599	That code would continue working with this proposal, except for<br />
600	a very rare corner case, in which it would leak.  In the normal<br />
601	case, (size != 0) would never be true under (new == NULL),<br />
602	because a reallocation of 0 bytes would almost always succeed,<br />
603	and thus not return a null pointer under this proposal.<br />
604	However, in some cases, the system might not find space even for<br />
605	the small metadata needed for a 0-byte allocation.  In such<br />
606	case, the (size != 0) conditional would prevent deallocating<br />
607	'old', and thus cause a memory leak.  This case is exceptional<br />
608	enough that it shouldn't stop us from fixing realloc(3).<br />
609	Anyway, on an out-of-memory case, the program is likely to<br />
610	terminate rather soon, so the issue is even less likely to have<br />
611	an impact on any existing programs.  Also, LLVM's address<br />
612	sanitizer will soon able to catch such a leak:<br />
613	<<a href="https://github.com/llvm/llvm-project/issues/113065>" rel="noopener">https://github.com/llvm/llvm-project/issues/113065></a><br />
614<br />
615	This proposal makes handling of realloc(3) as straightforward as<br />
616	one would expect, with only two states: success or error.  There<br />
617	are no in-between states.<br />
618<br />
619	The resulting wording in the standard is also much simpler, as<br />
620	it doesn't need to define so many special cases.<br />
621<br />
622	For consistency, all the other allocation functions are updated<br />
623	to both return a null pointer on error, and use consistent<br />
624	wording.<br />
625<br />
626    Why not go the other way around?<br />
627	Some people keep asking why not go the other way around: why not<br />
628	force the BSDs and musl to return a null pointer if size is 0.<br />
629	This would result in double-free and use-after-free bugs, which<br />
630	can result in RCE vulnerabilities (remote code execution), which<br />
631	is clearly unacceptable.<br />
632<br />
633	Consider this code, which is the usual code for calling<br />
634	realloc(3) in such systems:<br />
635<br />
636		new = realloc(old, size);<br />
637		if (new == NULL) {<br />
638			free(old);<br />
639			goto fail;<br />
640		}<br />
641		...<br />
642		free(new);<br />
643<br />
644	If realloc(p,0) would return a null pointer and free the old<br />
645	block, then the third line would be a double-free bug.<br />
646<br />
647Prior art<br />
648    gnulib<br />
649	gnulib provides the realloc-posix module, which aims to wrap the<br />
650	system realloc(3) and reallocarray(3) functions so that they<br />
651	behave in a POSIX-complying manner.<br />
652<br />
653	It previously behaved like glibc.  After I reported that it was<br />
654	non-conforming to POSIX, we discussed the best way forward,<br />
655	which we agreed was the same direction that this paper is<br />
656	proposing now for C2y.  The implementation was changed in<br />
657<br />
658		gnulib.git d884e6fc4a60 (2024-11-04; "realloc-posix: realloc (..., 0) now returns nonnull")<br />
659<br />
660	There have been no regression reports since then, as we<br />
661	expected.<br />
662<br />
663    V7 Unix, BSD<br />
664	The proposed behavior is the one endorsed by Doug McIlroy, the<br />
665	author of the original implementation of realloc(3) in V7 Unix,<br />
666	and also present in the BSDs.<br />
667<br />

668    glibc <= 2.1<br />
669	glibc was implemented originally to return non-null.  It was<br />
670	only in 1999, and purely to comply with the standards --with no<br />
671	requests by users to do so--, that the glibc maintainers decided<br />
672	to switch to the current behavior.<br />
673<br />
674Design decisions<br />
675	This change needs two changes, which can be applied all at once,<br />
676	or in separate steps.<br />
677<br />
678	The first step would make realloc(p,s) be consistent with<br />
679	free(p) and malloc(s), including when p is a null pointer, when<br />
680	s is zero, and also when both corner cases happen at the same<br />
681	time.  This change would already turn the implementations where<br />
682	malloc(0) returns non-null into the end goal we have.  This<br />
683	would require changes to (at least) the following<br />
684	implementations: glibc, Bionic, Windows.<br />
685<br />
686	The second step would be to require that malloc(0) returns a<br />
687	non-null pointer.  This would require changes to (at least) the<br />
688	following implementations: AIX.<br />
689<br />
690	This proposal has merged all steps into a single proposal.<br />
691<br />
692Caveats<br />
693    n?n:1<br />
694	Code written in the near future should be careful, in case it<br />
695	can run on older systems that are not fixed to comply with this<br />
696	stricter specification.  Thus, code written in the near future<br />
697	should call realloc(3) similar to this:<br />
698<br />
699		realloc(p, n?n:1);<br />
700<br />
701	When all existing implementations are fixed to comply with this<br />
702	stricter specification, that workaround can be removed.<br />
703<br />
704    ENOMEM<br />
705	Existing implementations that set errno to ENOMEM must continue<br />
706	doing so when the input pointer is not freed.  If they didn't,<br />
707	code that is currently portable to all POSIX systems<br />
708<br />
709		errno = 0;<br />
710		new = realloc(old, size);<br />
711		if (new == NULL) {<br />
712			if (errno == ENOMEM)<br />
713				free(old);<br />
714			goto fail;<br />
715		}<br />
716		...<br />
717		free(new);<br />
718<br />
719	would leak on error.<br />
720<br />
721	Since it is currently impossible to write code today that is<br />
722	portable to arbitrary C17 systems, this is not an issue in<br />
723	ISO C.<br />
724<br />
725		-  New code written for C2y will only need to check for<br />
726		   NULL to detect errors.<br />
727<br />
728		-  Code written for specific C17 and older platforms<br />
729		   that don't set errno will continue to work for those<br />
730		   specific platforms.<br />
731<br />
732		-  Code written for POSIX.1-2024 and older platforms<br />
733		   will continue working on POSIX C2y platforms,<br />
734		   assuming that POSIX will continue mandating ENOMEM.<br />
735<br />
736		-  Code written for POSIX.1-2024 and older will not be<br />
737		   able to be run on non-POSIX C2y platforms, but that<br />
738		   could be expected.<br />
739<br />
740	The only important thing is that platforms that did set ENOMEM<br />
741	should continue setting it, to avoid introducing leaks.]]></description><category>System Interfaces</category><pubDate>Mon, 10 Aug 2026 08:55:56 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1949</guid><comments>https://austingroupbugs.net/view.php?id=1949#bugnotes</comments></item><item><title>0001984: Ambiguous requirements for command -v on printing absolute pathnames</title><author></author><link>https://austingroupbugs.net/view.php?id=1984</link><description><![CDATA[The requirements for command -v read:&lt;br /&gt;
742&lt;br /&gt;
743- Executable utilities, regular built-in utilities, command_names including a &lt;slash&gt; character, and any implementation-provided functions that are found using the PATH variable (as described 

743in 2.9.1.4 Command Search and Execution), shall be written as absolute pathnames.<br />
744<br />
745This is ambiguous as to whether "that are found using the PATH variable" applies to "Executable utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-provided functions", or only to "any implementation-provided functions".<br />
746<br />
747Given that &quot;command_names including a &lt;slash&gt; character&quot; are never looked up using the PATH variable (as pointed out by Herbert Xu on the dash mailing list), the intent must be that &quot;that are found using the PATH variable&quot; applies only to &quot;any implementation-provided functions&quot;, but at least one shell (bash) does not currently write command_names including a &lt;slash&gt; character as absolute pathnames, even in POSIX mode, and in my opinion, the current text of the standard does not say it should.]]></description><category>Shell and Utilities</category><pubDate>Wed, 29 Jul 2026 07:19:22 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1984</guid><comments>https://austingroupbugs.net/view.php?id=1984#bugnotes</comments></item><item><title>0001993: pthread_create() should allow failure with ENOMEM, not just EAGAIN</title><author></author><link>https://austingroupbugs.net/view.php?id=1993</link><description><![CDATA[pthread_create() is currently defined to allow EAGAIN or EPERM. while _some_ resource issues fit EAGAIN, others do not warrant a retry loop. glibc and bionic both want to return ENOMEM in particular as an unretriable failure.]]></description><category>System Interfaces</category><pubDate>Tue, 28 Jul 2026 08:55:40 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1993</guid><comments>https://austingroupbugs.net/view.php?id=1993#bugnotes</comments></item><item><title>0001973: awk "numeric string " origins</title><author></author><link>https://austingroupbugs.net/view.php?id=1973</link><description><![CDATA[The awk specification (&lt;a href=&quot;https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/awk.html#tag_20_06_13_02&quot; rel=&quot;noopener&quot;&gt;https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/awk.html#tag_20_06_13_02&lt;/a&gt;) has:&lt;br /&gt;
748&lt;br /&gt;
749&lt;&lt;&lt;&lt;br /&gt;
750 A string value shall be considered a numeric string if it comes from one of the following:&lt;br /&gt;
751&lt;br /&gt;
752     1. Field variables&lt;br /&gt;
753     2. Input from the getline() function&lt;br /&gt;
754     3. FILENAME&lt;br /&gt;
755     4. ARGV array elements&lt;br /&gt;
756     5. ENVIRON array elements&lt;br /&gt;
757     6. Array elements created by the split() function&lt;br /&gt;
758     7. A command line variable assignment&lt;br /&gt;
759     8. Variable assignment from another numeric string variable&lt;br /&gt;
760&gt;&gt;&gt;&lt;br /&gt;
761&lt;br /&gt;
762It can be interpreted as meaning that&lt;br /&gt;
763&lt;br /&gt;
764awk 'BEGIN{$1 = &quot;10&quot;; print ($1 &gt; 2)}'&lt;br /&gt;
765&lt;br /&gt;
766should return 1 for instance. But no implementation that I know does so. By assigning a string to $1, it loses that special property whereby when containing a string that looks like a number it shall be considered as a number.&lt;br /&gt;
767&lt;br /&gt;
768Same applies for ARGV, FILENAME...&lt;br /&gt;
769&lt;br /&gt;
770Typo in rationale section btw:&lt;br /&gt;
771&lt;br /&gt;
772&gt; also shall have the numeric value of the numeric string&quot; was removed&lt;br /&gt;
773&gt;from several sections of the ISO POSIX-2:1993 standard because *is* &lt;br /&gt;
774&gt; specifies an unnecessary implementation detail&lt;br /&gt;
775&lt;br /&gt;
776is -&gt; it]]></description><category>Shell and Utilities</category><pubDate>Mon, 20 Jul 2026 16:11:56 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1973</guid><comments>https://austingroupbugs.net/view.php?id=1973#bugnotes</comments></item><item><title>0001987: The option value type for TCP_NODELAY is not specified.</title><author></author><link>https://austingroupbugs.net/view.php?id=1987</link><description><![CDATA[The option value type for TCP_NODELAY is not specified. This seem to be the case since at least Issue 6.&lt;br /&gt;
777&lt;br /&gt;
778Many other options have types of rank `int`, and their Windows counterparts often have DWORD or similar, as such I believe the type for this option value is most likely also `int`, rather than `_Bool` which may have issue with ABI compatibility.]]></description><category>Base Definitions and Headers</category><pubDate>Mon, 20 Jul 2026 15:36:02 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1987</guid><comments>https://austingroupbugs.net/view.php?id=1987#bugnotes</comments></item><item><title>0001991: touch -d 2026-06-29T00:00:60 should not be required to succeed</title><author></author><link>https://austingroupbugs.net/view.php?id=1991</link><description><![CDATA[The POSIX spec for 'touch' (POSIX.1-2024 page 3451 line 117731) specifies an option -d whose argument uses ISO 8601 notation to specify the time. However, if read literally there is a disagreement with ISO 8601 that I believe is unintentional, and which causes GNU coreutils 'touch' to fail to conform.&lt;br /&gt;
779&lt;br /&gt;

780The apparent disagreement was introduced in POSIX.1-2017, when -d was added with ISO 8601 syntax, but with semantics that seem to defer to the longstanding -t option in the treatment of the seconds (SS) field, namely, if SS is 60 that should mean the first second of the next minute. This meaning for SS contradicts ISO 8601, which says an SS value of 60 can only mean a leap second.<br />
781<br />
782I expect this disagreement with ISO 8601 was unintentional. Furthermore, the disagreement disagrees with GNU 'touch', which reserves SS=60 for true leap seconds which exist on (non-POSIX) platforms that support leap seconds.<br />
783<br />
784GNU 'touch' takes the not unreasonable position that it is helpful to catch typos, such as hours, minutes or seconds that are out of ISO 8601 range. POSIX surely did not intend to require implementations to implement timestamps in a way that disagrees with ISO 8601. Although some implementations, such as FreeBSD 'touch', treat &quot;:60&quot; as meaning the first second of the next minute, this behavior should not be required.]]></description><category>Shell and Utilities</category><pubDate>Mon, 13 Jul 2026 09:13:35 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1991</guid><comments>https://austingroupbugs.net/view.php?id=1991#bugnotes</comments></item><item><title>0001979: conflicting specification for open("existing-directory", O_RDONLY | O_CREAT, 0644)</title><author></author><link>https://austingroupbugs.net/view.php?id=1979</link><description><![CDATA[The description of open() explains O_CREAT with a paragraph that starts:&lt;br /&gt;
785&lt;br /&gt;
786O_CREAT   If the file exists, this flag has no effect except as noted under O_EXCL below.  &lt;...&gt;&lt;br /&gt;
787&lt;br /&gt;
788'file' is of course the XBD 'file' which includes directories, devices, etc.  So, open(O_RDONLY|O_CREAT) naming a directory that exists should behave the same as open(O_RDONLY) of that same path.&lt;br /&gt;
789&lt;br /&gt;
790Then later the ERRORS section contradicts that:&lt;br /&gt;
791&lt;br /&gt;
792[EISDIR]    The named file is a directory and oflag includes O_WRONLY or O_RDWR, or&lt;br /&gt;
793                  includes O_CREAT without O_DIRECTORY, or &lt;...&gt;]]></description><category>System Interfaces</category><pubDate>Mon, 13 Jul 2026 09:02:53 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1979</guid><comments>https://austingroupbugs.net/view.php?id=1979#bugnotes</comments></item><item><title>0001989: Confusing reference to "Symbol" for $0</title><author></author><link>https://austingroupbugs.net/view.php?id=1989</link><description><![CDATA[&gt; The symbol $0 shall refer to the entire record&lt;br /&gt;
794&lt;br /&gt;
795It's not a &quot;symbol&quot;, it's the $ operator applied to number 0 that yields the &quot;full record variable&quot;, $ 0, $(12/4-3) refer to the same variable.]]></description><category>Shell and Utilities</category><pubDate>Thu, 09 Jul 2026 15:25:35 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1989</guid><comments>https://austingroupbugs.net/view.php?id=1989#bugnotes</comments></item><item><title>0001988: Incorrect reference to "whole input record" for $0</title><author></author><link>https://austingroupbugs.net/view.php?id=1988</link><description><![CDATA[In&lt;br /&gt;
796&lt;br /&gt;
797&gt; The print statement shall write the value of each expression&lt;br /&gt;
798&gt; argument onto the indicated output stream separated by the&lt;br /&gt;
799&gt; current output field separator (see variable OFS above), and&lt;br /&gt;
800&gt; terminated by the output record separator (see variable ORS&lt;br /&gt;
801&gt; above). All expression arguments shall be taken as strings,&lt;br /&gt;
802&gt; being converted if necessary; this conversion shall be as&lt;br /&gt;
803&gt; described in Expressions in awk, with the exception that the&lt;br /&gt;
804&gt; printf format in OFMT shall be used instead of the value in&lt;br /&gt;
805&gt; CONVFMT. An empty expression list shall stand for the whole&lt;br /&gt;
806&gt; input record ($0).&lt;br /&gt;
807&lt;br /&gt;
808That late sentence is erroneous and misleading as $0's value is only the input record after that record has been read in and before it has been modified.]]></description><category>Shell and Utilities</category><pubDate>Thu, 09 Jul 2026 15:19:49 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1988</guid><comments>https://austingroupbugs.net/view.php?id=1988#bugnotes</comments></item><item><title>0001985: Add a dark theme to the HTML rendition</title><author></author><link>https://austingroupbugs.net/view.php?id=1985</link><description><![CDATA[Right now, there's only a light theme of the HTML rendition, which has a bright background.&lt;br /&gt;
809&lt;br /&gt;
810This may cause eye sore for some readers, who switches back and forth between their IDE and the standard text.]]></description><category>Base Definitions and Headers</category><pubDate>Thu, 02 Jul 2026 15:31:44 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1985</guid><comments>https://austingroupbugs.net/view.php?id=1985#bugnotes</comments></item><item><title>0001548: Addition of a POSIX.utf-8 locale (likely as 7.3 "POSIX.utf-8 locale")</title><author></author><link>https://austingroupbugs.net/view.php?id=1548</link><description><![CDATA[Today's modern POSIX systems use Unicode aware locales, almost all realized via the UTF-8 8-bit character set.&lt;br /&gt;
811Even though the standard(s) do not offer proper interfaces to deal with this, external libraries (GNU libunicode, ICU) fill this gap in practice.&lt;br /&gt;
812(These libraries can also be used with UTF-16 and UTF-32 character sets, the latter i think prefers the 16-bit encoding that is in use in a widely distributed commercial non-POSIX operating system.)&lt;br /&gt;
813&lt;br /&gt;
814As it stands users are using language/territory specific UTF-8 locales in real-life, like en_US.utf8 or de_DE.utf8.&lt;br /&gt;
815Right now there is no UTF-8 aka Unicode-spectrum POSIX locale available.&lt;br /&gt;
816&lt;br /&gt;
817Some operating systems (OpenBSD) and some libraries (musl LibC) however, and already, &quot;always work with UTF-8 8-bit&quot; Unicode, giving it the name &quot;C.UTF-8&quot; (musl; and as can be seen, the usual naming scheme mess continues).]]></description><category>Base Definitions and Headers</category><pubDate>Thu, 02 Jul 2026 12:38:11 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1548</guid><comments>https://austingroupbugs.net/view.php?id=1548#bugnotes</comments></item><item><title>0001990: This is a configuration test issue. Please ignore if you see this.</title><author></author><link>https://austingroupbugs.net/view.php?id=1990</link><description><![CDATA[Please ignore.]]></description><category>Base Definitions and Headers</category><pubDate>Thu, 25 Jun 2026 19:55:24 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1990</guid><comments>https://austingroupbugs.net/view.php?id=1990#bugnotes</comments></item><item><title>0001986: This is a configuration test issue. Please ignore if you see this.</title><author></author><link>https://austingroupbugs.net/view.php?id=1986</link><description><![CDATA[Test a new email notification configuration on the new hosting setup.]]></description><category>Base Definitions and Headers</category><pubDate>Thu, 25 Jun 2026 18:33:07 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1986</guid><comments>https://austingroupbugs.net/view.php?id=1986#bugnotes</comments></item><item><title>0001983: typo in sendmsg() EXAMPLES</title><author></author><link>https://austingroupbugs.net/view.php?id=1983</link><description><![CDATA[I'm forwarding a report I received by email from someone else.&lt;br /&gt;
818&lt;br /&gt;
819On 2026-06-02T15:02:40+0800, Zhai Can wrote:&lt;br /&gt;
820&gt; &lt;a href=&quot;https://man7.org/linux/man-pages/man3/sendmsg.3p.html&quot; rel=&quot;noopener&quot;&gt;https://man7.org/linux/man-pages/man3/sendmsg.3p.html&lt;/a&gt;&lt;br /&gt;
821&gt;&lt;br /&gt;
822&gt; In the EXAMPLES section it states a &quot;Done.&quot; which is weird here. I suppose it&lt;br /&gt;
823&gt; should be a &quot;None.&quot;? A quick grep shows the whole 3p manuals (2017) only have&lt;br /&gt;
824&gt; the one occurrence.&lt;br /&gt;
825&gt;&lt;br /&gt;
826&gt;   ~/man-pages-posix-2017/man3p ❯ rg Done.&lt;br /&gt;
827&gt;   sendmsg.3p&lt;br /&gt;
828&gt;   281:Done.&lt;br /&gt;
829&gt;&lt;br /&gt;
830&gt; It's an upstream issue. Also in:&lt;br /&gt;
831&gt;&lt;br /&gt;
832&gt; &lt;a href=&quot;https://pubs.opengroup.org/onlinepubs/9799919799/&quot; rel=&quot;noopener&quot;&gt;https://pubs.opengroup.org/onlinepubs/9799919799/&lt;/a&gt;&lt;br /&gt;
833&lt;br /&gt;
834Reported-by: Zhai Can &lt;&lt;a href=&quot;mailto:[email protected]&quot;&gt;[email protected]&lt;/a&gt;&gt;]]></description><category>System Interfaces</category><pubDate>Thu, 04 Jun 2026 15:16:40 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1983</guid><comments>https://austingroupbugs.net/view.php?id=1983#bugnotes</comments></item><item><title>0001981: Request to define ssize_t as the signed version of size_t</title><author></author><link>https://austingroupbugs.net/view.php?id=1981</link><description><![CDATA[Currently ssize_t is defined as:&lt;br /&gt;
835ssize_t shall be signed integer types.&lt;br /&gt;
836The type ssize_t shall be capable of storing values at least in the range [-1, {SSIZE_MAX}].&lt;br /&gt;
837&lt;br /&gt;
838But the sizeof ssize_t is not explicitly defined.&lt;br /&gt;
839&lt;br /&gt;
840And for glibc,musl,cygwin newlib, they all defined that sizeof(ssize_t)=== sizeof(size_t)&lt;br /&gt;
841&lt;br /&gt;
842And maybe because the sizeof ssize_t is not defined clearly. clang did n

842ot defined the sizeof of ssize_t well:<br />
843<br />
844<a href="https://github.com/llvm/llvm-project/issues/198975" rel="noopener">https://github.com/llvm/llvm-project/issues/198975</a><br />
845<br />
846<br />
847The glibc defined the sizeof ssize_t to be equal to size_t by the following codes:<br />
848#if __WORDSIZE == 32<br />
849# define __SWORD_TYPE		int<br />
850#else<br />
851# define __SWORD_TYPE		long int<br />
852#endif<br />
853<br />
854at<br />
855<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/types.h;h=33b582a8eabf09aadc093658db82353c288590d2;hb=HEAD#l118" rel="noopener">https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/types.h;h=33b582a8eabf09aadc093658db82353c288590d2;hb=HEAD#l118</a><br />
856<br />
857#define __SSIZE_T_TYPE          __SWORD_TYPE<br />
858at<br />
859<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/typesizes.h;h=466dd36681a7364952e49b73067d66174543cffd;hb=HEAD#l60" rel="noopener">https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/typesizes.h;h=466dd36681a7364952e49b73067d66174543cffd;hb=HEAD#l60</a><br />
860<br />
861__STD_TYPE __SSIZE_T_TYPE __ssize_t; /* Type of a byte count, or error.  */<br />
862at<br />
863<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/types.h;h=33b582a8eabf09aadc093658db82353c288590d2;hb=HEAD#l194" rel="noopener">https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/types.h;h=33b582a8eabf09aadc093658db82353c288590d2;hb=HEAD#l194</a><br />
864<br />
865#ifndef __ssize_t_defined<br />
866typedef __ssize_t ssize_t;<br />
867# define __ssize_t_defined<br />
868#endif<br />
869at<br />
870<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/sys/types.h;h=2b524761748fc2e0576e3b86fd5558e8a9ebcb18;hb=HEAD#l108" rel="noopener">https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/sys/types.h;h=2b524761748fc2e0576e3b86fd5558e8a9ebcb18;hb=HEAD#l108</a><br />
871<br />
872And the document of __WORDSIZE is:<br />
873/* Size in bits of the 'long int' and pointer types.  */<br />
874#define __WORDSIZE<br />
875at <br />
876<a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/wordsize.h;h=53013a9275c7c81eccb0356ab956eb2688bcf512;hb=HEAD#l7" rel="noopener">https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/wordsize.h;h=53013a9275c7c81eccb0356ab956eb2688bcf512;hb=HEAD#l7</a><br />
877<br />
878So basically glibc is already ensure ssize_t is the same size as size_t. Even thoug the command "/* Size in bits of the 'long int' and pointer types.  */" is a bit mis-leading.<br />
879As sizeof pointer will  not always have the same size as size_t.]]></description><category>Base Definitions and Headers</category><pubDate>Thu, 04 Jun 2026 15:12:53 +0000</pubDate><guid>https://austingroupbugs.net/view.php?id=1981</guid><comments>https://austingroupbugs.net/view.php?id=1981#bugnotes</comments></item></channel></rss>