b̲l̲e̲ scenarios (i.e. those in which you’re not
> > entering
> > unspecified behaviour already anyway), you’ll be safe with:
> >
> > x=$(command; echo .); x=${x%.}
> >
> > (Or a variant that carries over $?, of course.)
>
> ...
>
> I know you've
Christoph Anton Mitterer wrote, on 21 Feb 2022:
>
> On Mon, 2022-02-21 at 09:58 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > The reason the LC_ALL=C is needed to avoid unspecified behaviour is
> > because the description of the ${parameter%[word]} ex
e have
> had realpath(3) for a while).
>
> But the only option our realpath(1) has is -q ... no -e or -m options.
Does it have the same last-component-need-not-exist behaviour as the
GNU coreutils default, or is it just a wrapper round realpath(3)?
--
Geoff Clare
The Open Group, Ape
ded -E, FreeBSD would have no problem with
picking up that change.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
oth implementations). No realpath.
3. POSIX adds realpath without -e and -E, and readlink without -f.
Unspecified whether realpath needs last component to exist.
I wasn't proposing any other options be included for realpath
(except perhaps -q, depending on whether it behaves the same in
both
same behaviour on both.
>
> Yes, if it turns out not to be possible to alter the default behaviour
> of the default for our version, that would certainly be a reasonable
> approach.
Has there been any progress on the possibility of NetBSD changing
realpath to behave like coreutils wrt -e?
null pointer, realpath
shall write a diagnostic message to standard error and exit with
non-zero status.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
we ignore all errors here, or just ENOENT ? */
> }
> printf("%s\n", file);
> }
>
> (with error checking added, naturally).
>
> The second (similar caveats) is
>
> if ((path = realpath(file, NULL)) == NULL) {
>
Geoff Clare wrote, on 25 Mar 2022:
>
> > ln -s /tmp/gibberish/file d/link2
> > realpath d/link2
>
> $ realpath d/link2; echo exit $?
> realpath: d/link2: No such file or directory
> exit 1
I obviously didn't pay enough attention to this result,
he lines of your original
suggestion:
An escape sequence is defined as the escape character followed
by any single character. The escape character is a
that is neither in a bracket expression nor itself escaped.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
The escape character is a
> > that is neither in a bracket expression nor itself escaped.
>
> I think it should be the 2nd one
Okay, I'll propose that wording in Thursday's teleconference.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
t because
> of historical implementations and because of '(', ')', '{', and '}'.
> However, AFAIU, we need to *generally* rule that out, and not just
> because of historical implementations.
>
> And with "that" I mean, implementations must not be allowed to
> choose whether they give '\c' literal or special meaning, if 'c' is
> the delimiter, and if 'c' alone wouldn't be special, but 'c'
> preceded by an escaping '\' would be.
The proposed normative text does exactly that. The rationale is just
there to point out that the normative text disallows some historical
behaviour.
> VI) not really related to this issue, but it would make things even
> more complex if I add it in a separate ticket:
>
> The description of the y-command contains on page 3138, line 106249:
> "If the number of characters in string1 and string2 are not equal,
> or if any of the characters in string1 appear more than once, the
> results are undefined."
>
> That is strictly speaking wrong, namely in the case when string1
> and/or string2 contains '\'-escaped 'n' (for newline) or a '\'-escaped
> delimiters, and the number of occurrences in both strings don't even out.
>
> => Perhaps simply write "If the number of characters (after
> resolving any escape sequences)..." or so?
That part of the y command description is not being touched by the
changes to fix 1550 and 1551, so it would be best to raise a separate
bug for this.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
s defined as the escape character followed by
any single character, which is thereby "escaped". The escape
character is a that is neither in a bracket expression
nor itself escaped.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
h other characters,
even if that's the behaviour the user wants. Rather than try to come
up with new descriptive words, I think it could be illustrated with
an example, e.g. adding:
For example, the context address "\.[.][0-9]." is equivalent
to "/\.[0-9]/".
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
; Do you think anything should be done about that?
I think a new bug report asking for:
A portable BRE shall escape a trailing in a
subexpression to match a literal .
to be added would likely be accepted.
I think the angle brackets should be there on that last word - they
are missing for circumflex and it would be good if the same bug could
ask for that to be fixed too.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Christoph Anton Mitterer wrote, on 08 Apr 2022:
>
> btw: I'll still need till next week to look into Geoff's replies to my
> last comments in #1550.
As you have probably seen, I have posted an updated proposal to
bug 1550. Hopefully that will help with your review.
--
Ge
s not a valid file
descriptor open for reading and there is no buffered data
available to be returned.
(adding the "and ..." part).
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ecified as containing 256 single-byte characters.
Thus in the C locale all pathnames are valid character strings.
> Even worse perhaps, ???.doc which should match 7 char
> names that end in ".doc" (or is that 7 byte names?) (not counting the \0).
It would match 7-byte names.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Christoph Anton Mitterer wrote, on 18 Apr 2022:
>
> On Tue, 2022-04-05 at 15:54 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > > ---
> > > ---
> > > (0005771) calestyo (repor
as, and enter the appropriate number of '?'
> chars?
The point of adding an explicit statement to normative text is to draw
attention to the issue. Thus users should be aware that ???.doc will
match 7-byte names, and if that's not what they want then they will need
to find a different way to obtain the result they want.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
quot;) if the string to be matched does not consist of valid
characters.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
sequence of 1-n IFS
> characters were still regarded as one single field splitter.
>
> With the new:
> "ignored and any sequence of such bytes"
> that's IMO a bit lost... sequence of bytes is rather considered like ONE
> "multi-byte" character.
Each of the
Geoff Clare wrote, on 22 Apr 2022:
>
> I'll insert "(one or more instances)".
And having done so, the use of "zero or more instances" in the
paragraph about IFS white space now seems wrong to me. I think it
should be one or more as well.
--
Geoff Clare
The Open
et/view.php?id=1561#c5668
>
> Should page 2351, line 76081-76082 include a note with respect to what's
> been said in page 2335, lines 75446-75449 and their counterparts on page
> 2336, lines 75469-75472 namely that in addition to the variables with
> export attribute, also such with invalid names *might* be passed on
> (respectively that it's unspecified whether or not)?
I assume you mean 76079-76080 (since 76081-76082 are about the
environment of the invoking shell not being affected by the utility it
invoked).
It might we worth adding something there, but I think that's a separate
issue and so should be dealt with in a separate bug.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
7;s more clear where the string is a character string.
You assume correctly.
> But what about line 3095, should it read "An optional CHARACTER string of
> decimal digits to specify" - or is that already clear enough because of it
> containing of decimal digits?
It's already clea
d breaks it already!
This was discussed during our work on bug 1233 and resulted in additions
to the sed APPLICATION USAGE (line 106286 in draft 2.1) and FUTURE
DIRECTIONS.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Christoph Anton Mitterer wrote, on 25 Apr 2022:
>
> On Fri, 2022-04-22 at 12:03 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> >
> > > 3) You introduce bytes/byte sequences vs. characters.
> > >
> > > I don't understand why you
Christoph Anton Mitterer wrote, on 25 Apr 2022:
>
> On Fri, 2022-04-22 at 15:36 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > > However some shells may e.g. wish to provide such invalidly named
> > > env vars
> > > in a special shell v
rrent proposal in #1550’s note #5816.
Excellent news. Thank you.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Christoph Anton Mitterer wrote, on 26 Apr 2022:
>
> On Mon, 2022-04-25 at 10:21 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > This was discussed during our work on bug 1233 and resulted in
> > additions
> > to the sed APPLICATION USAGE (line 1062
ld need to change in order to conform.)
B. Allow remove-before-prompting. This would mean changing 2.9.3.1 to
add a third list item (for interactive shells only) and deleting the
above quoted text from the wait page.
I'm particularly interested to get the opinions of shell authors on
this.
teract with maintenance of the jobs command,
> the wait command, and all else related.
I have a vague recollection of this coming up before, but I don't
remember whether it was in a Mantis bug or a mailing list thread.
I don't think this needs to be addressed in bug 1254; it could just
be ha
the "must remain ignored" (in the standard not yet written).
>
> Not really a good scheme, and didn't work at all on processors that could
> not resume (repeating the offending instruction) after having received a
> SEGV (like the original 68000 for example).
>
> |
ution in case the work on (1561 or) 1564
results in some change to the resolution.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
or the background jobs list, making it clear that it is not the same
things as the known process IDs list (which already has an entry).
There are already cross-references to 2.12 where the known process IDs
are mentioned, so it would also be the natural place to reference for
the background jobs list.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
o that it doesn't do that. Hopefully the
other ash-bashed shells will follow suit. If you only change
bash in POSIX mode, you will be doing your users a disservice.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Chet Ramey wrote, on 06 May 2022:
>
> On 5/5/22 7:46 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> > The fact that the jobs command works with job control disabled is
> > mentioned in the rationale on the jobs page:
> >
> > The jobs ut
Chet Ramey wrote, on 11 May 2022:
>
> On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> >> I'd be interested in your reasoning. The standard simply says that jobs
> >> and kill (and wait should be added) work with job %X notation wh
ed.
However, it is an internal implementation detail how that is managed.
If you want to have one table with some flag to say whether each
entry is a job or a "known process ID that's not a job", that's fine.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ble to always use the %n (etc) notation to manipulate
> such jobs, but they very clearly are jobs.
>
> Hence no such flag is required. Knowing whether the job was
> started under job control, and hence has a pgrp of its own,
> is required, but that is a different thing entirely.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Chet Ramey wrote, on 13 May 2022:
>
> On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> > The definition of "Job" is:
> >
> > A set of processes, comprising a shell pipeline, and any processes
> > descended from
ignoring the duplicates."
>
[...]
>
> Suggestion:
> Remove these lines.
In today's call we removed those lines.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ports searches
> across multiple locale names."
In today's call we made changes along the lines you suggest. Please
check the updated etherpad to see if they achieve what you wanted.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ger separate steps, but such that backtracking occurs when the
> messages object does not contain a translation for the given msgid.
> This would resolve the apparent contradiction with lines 339, 340.
In today's call we made changes along the lines you suggest. Please
check the updated
> "over <...>"
> to
> "over <...>, if the latter is not the POSIX locale"
In today's call we made changes along the lines you suggest. Please
check the updated etherpad to see if they achieve what you wanted.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
as a helper
> function.
This was discussed in today's call, but we did not reach a conclusion.
Can you explain how glibc manages not to invalidate strings returned
by gettext() when uselocale() is used to change the locale (without
leaking memory - or does it leak memory?), in particular if codeset
translation was needed.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
e seen on page 26 lines 928-935
of C17_alignment_20211019.pdf which is the bug 1302 attachment
referenced in the "Final Accepted Text" field of that bug.
https://austingroupbugs.net/view.php?id=1302
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Fred J. Tydeman wrote, on 19 May 2022:
>
> On Wed, 18 May 2022 09:30:51 +0100 Geoff Clare via austin-group-l at The Open
> Group wrote:
> >
> >Fred J. Tydeman wrote, on 17 May 2022:
> >>
> >> The 202x version I have, in , shows tv_nsec tagged as CX.
>
thread-safe except where explicitly
stated otherwise, and there is no exception for gettext stated in the
etherpad.
The requirement is intended to forbid the use of a thread-local
static buffer to store the returned string.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
b
> 002
>
> Whereas on Solaris, \c is not interpreted:
>
> $ gettext -s -e 'ab\c' | od -t c
> 000 a b c \n
> 004
>
> How to resolve this?
In today's call we made changes to allow this handling of \c (using "may",
so it is a
32", "UTF-32BE",
> "UTF-32LE", "UTF-7"."
In today's call we made changes along the lines you suggest. Please
check the updated etherpad to see if they achieve what you wanted.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
in forcing gettext() to accept the converted
> string when it has low quality.
In today's call we made changes along the lines you suggest. Please
check the updated etherpad to see if they achieve what you wanted.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
> Suggestion: Change
> "after the application"
> ->
> "after the application or library"
In yesterday's call we made this change and also added "or libraries" at
the end of the sentence.
[I mistakenly said "today's call" in some earlier mails.]
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
> were different.
>
> 'restrict' is meaningful when at least one of the parameters is a
> writable pointer type. Here, all parameters are either non-pointers
> or read-only pointers.
>
> Suggestion: Remove every 'restrict' in these declarations.
In yesterday&#
ject to
uselocale() to set a thread-local current locale which must then
be used by functions that use the current locale, such as scanf()
and strtol(). These functions only use the "global locale" (set
by setlocale()) if there is no thread-local current locale set.
--
Geoff Clare
Th
why it is the only one that has mention of how
each deals with the part of NLSPATH meant for the other.
We added text after each "Example ..." heading to make it clear which
type of application the example is aimed at.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Bruno Haible wrote, on 12 May 2022:
>
> https://posix.rhansen.org/p/gettext_draft
> Line 668
>
> Typo: msgid_pural -> msgid_plural
Thanks for spotting this. It was corrected in today's teleconference.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
lso missing a trailing newline, which means the input is
not a text file and the behaviour is unspecified. If you add the missing
newline, the 2nd and 3rd lines in your example should be converted to
"\ta\n\t\t a\n", and all the implementations I tried did that.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
does GNU xgettext deviate?
>
> I think there are three reasons:
>
[...]
>
> Suggestion:
> Mark this case as unspecified.
In today's teleconference we made changes to allow both behaviours,
although we made it implementation-defined rather than unspecified.
(I.e. implementations have to document which way they behave.)
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Bruno Haible wrote, on 25 May 2022:
>
> Geoff Clare wrote:
> > > https://posix.rhansen.org/p/gettext_draft
> > > Line 357
> > > ...
> > > If temporarily switching a thread's locale through uselocale()
> > > invalidates the gettext functions
raight away.
>
> Wouldn't that rather be “if a file operand *named* a FIFO special file
> and what waited for an end-of-file condition”?
Now that you point it out, that does seem a bit odd. I have changed
it to say "named".
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ough I suppose a reader might wonder whether a string could be
split across a statement and a statement continuation; they would soon
realise it cannot when they read, later in the same paragraph, that a
statement continuation is "a double-quoted string on a line by itself".)
So I don't
the functions with an _l suffix if they are used."
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
string or has a colon and number(s)
after the id. However, "pattern" isn't appropriate either as there
is no pattern matching operation performed.
I would suggest "keyword-spec", and I have put that in for now.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
text will
write those strings literals to the .po file. It would be a useful
future enhancement to msgfmt if it could support these sequences.
We don't want POSIX to forbid this enhancement, as it is possible
it will be requested by users during the lifetime of the next
POSIX revision.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
identifier (line 901) and untranslated_string_plural (line 902).
>
> Both GNU msgfmt and Solaris msgfmt do it like this.
In today's teleconference we struck out the word "message", so that it
reads: "C-language escape sequences in strings shall be processed ..."
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
t that this
directive is optional in the default output file.
This allows both the Solaris and GNU behaviours.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
helpful if you could review the latest changes this week.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
gt; Minutes of the 21st July 2022 TeleconferenceAustin-1241 Page 1 of 1
> > Submitted by Andrew Josey, The Open Group. 22nd July 2022
> >
> > Attendees:
> >Don Cragun, IEEE PASC OR
> >Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
>
ustin- Page 1 of 1
Submitted by Geoff Clare, The Open Group.5th August 2022
Attendees:
Don Cragun, IEEE PASC OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Eric Ackermann, HPI, University of Potsdam
Geoff Clare, The Open Group
Tom Thompson, IEEE
Mark Zi
ustin- Page 1 of 1
Submitted by Geoff Clare, The Open Group.9th August 2022
Attendees:
Don Cragun, IEEE PASC OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Mark Ziegast, SHware Systems Dev.
Eric Ackermann, HPI, University of Potsdam
Geoff Clare, The Open
ipt needs a #! line
(and can only meet the requirements on systems that support #!).
I'll submit a bug in Mantis when I get time (and if nobody else beats
me to it).
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ustin- Page 1 of 1
Submitted by Geoff Clare, The Open Group. 26th August 2022
Attendees:
Don Cragun, IEEE PASC OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Mark Ziegast, SHware Systems Dev.
Eric Ackermann, HPI, University of Potsdam
Geoff Clare, The Open
st instance which is preserved and subsequent
> instances are omitted, which means order is preserved. Is that
> requirement intentional?
It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4
and FreeBSD implementations and they all expanded $^ (or $> for
FreeBS
never existed, or,
> if you read it prochronologically, -xcase was removed in error.
I agree this should say xcase(-xcase). Since there has been a change
to the stty page since draft 2.1 (for bug 1508) I will fix this as
part of the change history updates that go into draft 3.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
rget contain any .WAIT special
> > targets, the results of expanding $^ are unspecified.
> >
> > [example omitted]
>
> Thanks, but what about the other internal macros that may refer to
> prerequisites? Don't we need to specify the .WAIT behav
Paul Smith wrote, on 09 Sep 2022:
>
> On Fri, 2022-09-09 at 10:19 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > It's intentional. I tried 'all: a b a c' with the GNU, Solaris 11.4
> > and FreeBSD implementations and they all expanded
Paul Smith wrote, on 09 Sep 2022:
>
> On Fri, 2022-09-09 at 16:02 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > > > $^
> > > > The $^ macro shall evaluate to the list of prerequisites
> > > > for th
ld intentionally
use .WAIT in those ways, but obviously they could arise through
expansion of an empty macro.
I think we should tweak the text at the next opportunity to add
"(if any)" in the appropriate places. I'll make a note to submit
a bug against draft 3 to request that change.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
to 2.9.5]).
After posting this I realised that this is the wrong place for the
last bullet item, as it should always apply, not just under the
conditions stated here. So I have edited the note to put this as
replacement text for the current similar text in OPERANDS (instead
of deleting that text)
sense out of it is to take it as meaning
that when the thread moves from the queue for the higher priority to
the queue for its original priority, it should be placed at the head
not the tail, which seems reasonable, but it's very unclear.
What do implementations actually do?
--
Geoff Cl
ng, but now at its original priority (unless unlocking the
mutex makes a higher priority thread runnable, in which it would be
pre-empted by the higher priority thread).
However, the last bit "in the event that its original priority is changed"
still makes no sense.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
"XXX" or "")"
> \e seems a particularly bad example thus.
>
> (Also quotation-mark does not _need_ to be escaped, it can. It
> might be worthwhile to point this out? A few lines earlier.)
I can't see anything "a few lines earlier" that implies quotation-mark
needs to be escaped. Please give the exact wording change you would
like to see.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ing and second thread
that is runnable but not running.
The rationale says "When selecting a process to run, the system always
selects the first process from the highest priority queue with a
runnable process." But the first process in the queue is already
running - it would need to say that the system selects the first
process that isn't already running. (Again, it should say thread not
process.)
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
uded
>
> (just before the '.' that ends the existing sentence).
Thanks, I see Steffen's point now. I have added:
, but note that can be included unescaped
to the bug249 etherpad page in blue.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Joel Sherrill wrote, on 19 Oct 2022:
>
> On 10/19/2022 3:12 AM, Geoff Clare via austin-group-l at The Open Group
> wrote:
> > I wrote, on 11 Oct 2022:
> >>
> >> I wrote, on 10 Oct 2022:
> >>>
> >>> I'm try
e Implementation, known as
> "tzcode", is used by many if not most platforms, and has been for many
> many years.
If it returns -1 for times "in the gap" then it isn't being used by any
certified UNIX or POSIX system, nor by Debian GNU/Linux (or any other
Linux distro, I assume, but that's the one I tested).
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
not shared by most if not all
of the POSIX/UNIX implementors except, presumably Paul Eggert). In fact,
the benefit for applications would be negative because in addition to
making them add the extra code to handle the error, it would make it
harder for applications that want to detect the "time in the gap" case
to do so as they would need to find a way to distinguish this EINVAL
error from a fatal EINVAL error.
The glibc source has a comment which supports this:
The requested time probably falls within a spring-forward gap of
size DT. Follow the common practice in this case, which is to
return a time that is DT away from the requested time, preferring
a time whose tm_isdst differs from the requested value. (If no
tm_isdst was requested and only one of the two values has a nonzero
tm_isdst, prefer that value.) In practice, this is more useful
than returning -1.
Note the last sentence.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
d will not fit in
a time_t, which isn't the case for times in the gap. (This derives from
another general rule in XSH 2.3).
> | And it would be for nothing: there is nothing to be gained except to
> | satisfy your idealistic notion of correctness
>
> On this we simply must ag
Robert Elz wrote, on 09 Nov 2022:
>
> From: "Geoff Clare via austin-group-l at The Open Group"
>
>
> | We are going round in circles. You already asked that (probably in
> | different words) and I already answered it.
>
> Which implies th
Geoff Clare wrote, on 10 Nov 2022:
>
> I agree that it would worthwhile to clarify this in POSIX. Perhaps we
> should change:
>
> Upon successful completion, the values of the tm_wday and tm_yday
> components of the structure shall be set appropriately, and the
>
ov 2022:
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> You seem to be of the opinion that mktime()'s prime purpose is to allow
> people to increment time fields, and get a time_t back. Almost as if
> that is its only use.
Of course I am
Robert Elz wrote, on 24 Nov 2022:
>
> Date:Tue, 22 Nov 2022 12:49:13 +
> From: "Geoff Clare via austin-group-l at The Open Group"
>
>
> | Having returned refreshed from my break, I have re-examined this issue
> | and I now have a c
Robert Elz wrote, on 25 Nov 2022:
>
> Date:Thu, 24 Nov 2022 15:49:49 +
> From: "Geoff Clare via austin-group-l at The Open Group"
>
>
> | Combining the above with the TZ rules, if TZ=EST5EDT then POSIX requires
> | that mktime() cal
s would be invention.
If you want to propose further additions you will need to persuade
an implementation to add them first.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
its use
there to have been an editorial error and for consistency it should be
changed to "null terminator".
If you open an issue, please ask for getdelim() to be changed.
Adding a definition of "null terminator" would also be worthwhile.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Robert Elz wrote, on 04 Dec 2022:
>
> Date:Mon, 28 Nov 2022 09:35:25 +
> From: "Geoff Clare via austin-group-l at The Open Group"
>
>
This entire email is underhanded and dishonest. You have completely
ignored my earlier email (austin-gro
Robert Elz wrote, on 06 Dec 2022:
>
> Date:Tue, 6 Dec 2022 12:01:52 +
> From: "Geoff Clare via austin-group-l at The Open Group"
>
>
> | You have completely
> | ignored my earlier email (austin-group-l:archive/latest/35115) where
&g
ated by POSIX)).
There are no plans for that. And given the short time available
before we produce draft 3, I doubt it would be feasible for Issue 8.
(New features need to be in draft 3 if they are going to make it
into Issue 8 rather than waiting for Issue 9.)
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
able to extract files whose pathnames
contain newlines (except by renaming them with -s or -i), that doesn't
seem like a good enough reason to add -0. You can see that they exist
by listing with "pax -v" and noting which lines have no mode, user,
group, size, etc. (or just attemp
501 - 600 of 729 matches
Mail list logo
