[Issue 8 drafts 0001489]: malloc RATIONALE awkward wording
The following issue has been set as RELATED TO issue 0001387. == https://austingroupbugs.net/view.php?id=1489 == Reported By:rhansen Assigned To: == Project:Issue 8 drafts Issue ID: 1489 Category: System Interfaces Type: Error Severity: Editorial Priority: normal Status: New Name: Richard Hansen Organization: User Reference: Section:malloc RATIONALE Page Number:1272 Line Number:42599 Final Accepted Text: == Date Submitted: 2021-07-12 16:09 UTC Last Modified: 2021-07-12 16:10 UTC == Summary:malloc RATIONALE awkward wording == Relationships ID Summary -- related to 0001387 Should EAGAIN be acceptable for malloc ... == Issue History Date ModifiedUsername FieldChange == 2021-07-12 16:09 rhansenNew Issue 2021-07-12 16:09 rhansenName => Richard Hansen 2021-07-12 16:09 rhansenSection => malloc RATIONALE 2021-07-12 16:09 rhansenPage Number => 1272 2021-07-12 16:09 rhansenLine Number => 42599 2021-07-12 16:10 rhansenRelationship added related to 0001387 ==
[1003.1(2008)/Issue 7 0001387]: Should EAGAIN be acceptable for malloc failure?
The following issue has been set as RELATED TO issue 0001489. == https://austingroupbugs.net/view.php?id=1387 == Reported By:rhansen Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 1387 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: Applied Name: Richard Hansen Organization: User Reference: Section:malloc Page Number:1295 (Issue 7 2018 edition) Line Number:43161 (Issue 7 2018 edition) Interp Status: Approved Final Accepted Text:https://austingroupbugs.net/view.php?id=1387#c5203 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2020-08-10 16:46 UTC Last Modified: 2021-03-08 15:18 UTC == Summary:Should EAGAIN be acceptable for malloc failure? == Relationships ID Summary -- related to 0001489 malloc RATIONALE awkward wording == Issue History Date ModifiedUsername FieldChange == 2020-08-10 16:46 rhansenNew Issue 2020-08-10 16:46 rhansenStatus New => Under Review 2020-08-10 16:46 rhansenAssigned To => ajosey 2020-08-10 16:46 rhansenName => Richard Hansen 2020-08-10 16:46 rhansenSection => malloc 2020-08-10 16:46 rhansenPage Number => 1295 (Issue 7 2018 edition) 2020-08-10 16:46 rhansenLine Number => 43161 (Issue 7 2018 edition) 2020-08-10 16:46 rhansenInterp Status => --- 2020-08-10 17:09 rhansenNote Added: 0004914 2020-08-10 17:14 rhansenDescription Updated 2020-08-10 17:35 rhansenDesired Action Updated 2020-08-10 17:36 rhansenDesired Action Updated 2020-08-10 17:39 Don Cragun Note Added: 0004915 2020-08-10 17:45 alanc Note Added: 0004916 2020-08-10 17:45 alanc Note Edited: 0004916 2020-08-11 01:08 shware_systems Note Added: 0004918 2020-08-14 09:50 joerg Note Added: 0004923 2020-08-14 09:50 joerg Note Edited: 0004923 2020-08-14 09:51 joerg Note Edited: 0004923 2020-08-19 09:53 Konrad_Schwarz Note Added: 0004927 2020-08-19 19:57 rhansenNote Added: 0004932 2020-08-20 07:23 Konrad_Schwarz Note Added: 0004933 2020-08-20 17:58 rhansenNote Added: 0004935 2020-08-20 18:04 rhansenNote Edited: 0004935 2020-08-20 18:08 rhansenNote Edited: 0004935 2020-08-20 18:10 rhansenNote Edited: 0004935 2020-08-20 18:14 alanc Note Added: 0004936 2020-08-20 18:24 rhansenNote Added: 0004937 2020-08-20 18:25 rhansenNote Edited: 0004937 2020-08-20 18:25 rhansenNote Edited: 0004937 2020-08-20 18:30 rhansenNote Added: 0004938 2020-08-20 19:42 alanc Note Added: 0004939 2020-08-20 19:44 rhansenNote Edited: 0004937 2020-08-20 19:48 rhansenNote Added: 0004940 2020-08-20 19:49 rhansenNote Edited: 0004940 2020-08-20 19:49 rhansenNote Edited: 0004940 2021-01-21 16:11 geoffclare Note Added: 0005203 2021-01-21 16:13 geoffclare Interp Status--- => Pending 2021-01-21 16:13 geoffclare Final Accepted Text => https://austingroup
[Issue 8 drafts 0001489]: malloc RATIONALE awkward wording
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1489 == Reported By:rhansen Assigned To: == Project:Issue 8 drafts Issue ID: 1489 Category: System Interfaces Type: Error Severity: Editorial Priority: normal Status: New Name: Richard Hansen Organization: User Reference: Section:malloc RATIONALE Page Number:1272 Line Number:42599 Final Accepted Text: == Date Submitted: 2021-07-12 16:09 UTC Last Modified: 2021-07-12 16:09 UTC == Summary:malloc RATIONALE awkward wording Description: I find "since when" a bit difficult to read, and "described there" to be a bit misleading. Desired Action: On page 1272 lines 42599-42600 (malloc RATIONALE), change:Section 2.3 (on page 471) permits this behavior, since when multiple error conditions described there are simultaneously true there is no precedence between them.to:Section 2.3 (on page 471) permits this behavior; when multiple error conditions are simultaneously true there is no precedence between them. == Issue History Date ModifiedUsername FieldChange == 2021-07-12 16:09 rhansenNew Issue 2021-07-12 16:09 rhansenName => Richard Hansen 2021-07-12 16:09 rhansenSection => malloc RATIONALE 2021-07-12 16:09 rhansenPage Number => 1272 2021-07-12 16:09 rhansenLine Number => 42599 ==
Austin Group teleconference +1 888 974 9888 PIN 618 156 403
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:20120311T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:60ec6860c4...@opengroup.org DTSTAMP:20210712T160552Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20210712T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 19-Jul-2021 at 11: 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open group.org/platform/single_unix_specification/events.php\n\n* All calls are anchored on US time **\n\nTopic: Austin Group teleconference\n--- \nAudio conference information \n---\n\nYou are invit ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone: \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n \nOr iPhone one-tap (US Toll): +16699006833\,618156403# or +16465588656\, 618156403#\n\nPassword for zoom call ends with x\n\nAll Austin Group part icipants are most welcome to join the call.\nThe call will last for 90 min utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN R EQUIRED to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n \n\n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20210719T11 DURATION:PT1H30M0S LAST-MODIFIED:20210712T120552Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
Re: utilities and write errors
"Robert Elz via austin-group-l at The Open Group" wrote: > The bosh test is not useful though, since it doesn't bother to do > the required output at all ... > > bosh $ echo $PWD $OLDPWD > /tmp/b /tmp/a > bosh $ cd - > bosh $ echo $PWD $OLDPWD > /tmp/a /tmp/b Thank you for the hint, I changed that to print the directory in case that the target directory name differs from the cd parameter. Jörg -- EMail:jo...@schily.net Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Re: utilities and write errors
Date:Mon, 12 Jul 2021 09:48:33 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210712084833.GA31700@localhost>
| That's not the only way. The usual traversal via .., ../.., etc. could
| be done, but just storing dev/ino pairs on the way up and then reading
| the directories and looking for those stored values on the way down.
One could do almost anything. But why would anyone bother?
| Or, a modern implementation could open a file descriptor for each
| directory instead of storing dev/ino, and use openat() and fdopendir()
| on the way down.
A modern implementation would use getcwd() - only an implementation from
before that existed would implement manual scanning in pwd itself, and one
from that long ago would not contemplate that method (even if it had been
possible back then) as the path depth would be limited by the number of
available file descriptors (now, not a problem, but back then, with just
16 or 20, a real issue - even now if RLIMIT_NOFILE is set low enough.)
The argument (assuming a non getcwd() implementation) that you should be
making is that the implementation (working up the tree) might store each
file name (path name component) in a separate buffer - perhaps even still
in the buffer as read from the directory, and then construct the final result
with a
next = root_dir_entry;
while (next != NULL) {
printf("/%s", next->name); /* note next->name can
be "" */
next = next->nxt;
}
printf("\n");
type loop, so it never needs to malloc() a buffer for the string, or strlen()
it, or realloc() it (possibly many times) as it grows.
That would be a plausible (prohibited) implementation (though if one ensured
sufficient buffer size for standard output buffering, and always forced it
on, perhaps not prohibited .. do the same thing using write() instead of
printf for an obviously prohibited, but plausible, version).
There's no real reason this needs to be prohibited though, you're certainly
right that the reason for the prohibition is almost certainly to prevent
writing before all the components have been determined, not to attempt to
control the number of write() system calls issued (a version using old stdio,
from before line buffering, writing to a terminal, would probably do one
write sys call for each character in the output).
That's why it is a bit weird, as it is hard to imagine any implementation,
from any era, ever behaving the way that is intended to prohibit - the whole
thing looks like someone's imagined "but they might..." musing, ignoring the
fact that no-one ever actually would.
| I have already pointed out (not sure if I actually quoted them) the
| parts of the standard that make it crystal clear that it requires what
| I say it requires.
Sorry, that was never clear to me. Still isn't.
| As a reminder, these are the relevant parts of the standard:
|
| 1. The pwd DESCRIPTION and STDOUT say it writes an absolute pathname
| of the current working directory to standard output. (And it is clear
| that this is the sole purpose of pwd.)
Sure, though the "sole purpose" thing seems to be an invention thrown in
here because of discussions during this debate - that's not mentioned (as
an attribute, nor as a goal for any particular requirement, in the standard
either).
| 2. The meaning of "standard output"
Let's forget that "issue", which isn't an issue - no-one is really
debating that (despite some of the earlier messages). Further, it
doesn't really matter what it means to this discussion. It is where
we send the output, and if someone ever got that wrong, that would be
a completely different discussion.
| 3. The pwd EXIT STATUS section says that status 0 means "Successful
| completion".
Sure.
| Together these things constitute a requirement that pwd only exits
| with status 0 if it has successfully written an absolute pathname of
| the current working directory to file descriptor 1.
No they don't, that's a conclusion you're jumping to. It might seem to
make sense, but nothing anywhere actually says that.
It says we have to write to standard output, pwd (the version I use) does
that. It says to exit(0) when that has happened and pwd is satisfied,
my version does that. It nowhere explicitly says that anything is required
to check the status of the write. Even now you haven't attempted to show
anywhere that it does. You're just assuming that "write to standard output"
means that the output must have successfully been transferred somewhere.
You believe that your view is the only thing that makes sense. But I know
it cannot be correct, because POSIX was documenting the standard behaviour,
of the implementations, the same as it still does (or should) and this was
not a case where there was any real deviation. No-one checked that kind of
thing, so to pretend (or require) that they did would n
[1003.1(2016/18)/Issue7+TC2 0001488]: pwd RATIONALE does not account for ENOSPC
The following issue has been SUBMITTED. == https://austingroupbugs.net/view.php?id=1488 == Reported By:geoffclare Assigned To: == Project:1003.1(2016/18)/Issue7+TC2 Issue ID: 1488 Category: Shell and Utilities Type: Error Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section:pwd Page Number:3131 Line Number:104830 Interp Status: --- Final Accepted Text: == Date Submitted: 2021-07-12 09:31 UTC Last Modified: 2021-07-12 09:31 UTC == Summary:pwd RATIONALE does not account for ENOSPC Description: The part of the pwd RATIONALE that talks about partial output does not take into account the possibility of an ENOSPC condition causing a partial write. The normative text in CONSEQUENCES OF ERRORS would also benefit from a small change, as the current text can be interpreted as requiring pwd to travel back in time and change what it has already done. Since time travel isn't possible, such an interpretation is obviously incorrect, but it is worth updating the text to stop readers trying to interpret it that way. Desired Action: On page 3131 line 104819 section pwd, change:If an error is detected, output shall not be written to standard output, a diagnostic message shall be written to standard error, and the exit status is not zero.to:If an error is detected other than a write error when writing to standard output, no output shall be written to standard output, a diagnostic message shall be written to standard error, and the exit status shall be non-zero. On page 3131 line 104830 section pwd, change:In most utilities, if an error occurs, partial output may be written to standard output. This does not happen in historical implementations of pwd. Because pwd is frequently used in historical shell scripts without checking the exit status, it is important that the historical behavior is required here; therefore, the CONSEQUENCES OF ERRORS section specifically disallows any partial output being written to standard output.to:In most utilities, if an error occurs, partial output may be written to standard output. This does not happen in historical implementations of pwd (unless an [ENOSPC] condition causes a partial write). Because pwd is frequently used in historical shell scripts without checking the exit status, it is important that the historical behavior is required here; therefore, the CONSEQUENCES OF ERRORS section specifically disallows any partial output being written to standard output, except when a write error occurs when writing to standard output. == Issue History Date ModifiedUsername FieldChange == 2021-07-12 09:31 geoffclare New Issue 2021-07-12 09:31 geoffclare Name => Geoff Clare 2021-07-12 09:31 geoffclare Organization => The Open Group 2021-07-12 09:31 geoffclare Section => pwd 2021-07-12 09:31 geoffclare Page Number => 3131 2021-07-12 09:31 geoffclare Line Number => 104830 2021-07-12 09:31 geoffclare Interp Status => --- ==
Re: utilities and write errors
Robert Elz wrote, on 09 Jul 2021:
>
> | The whole
> | point of that bit of rationale is that pwd should not write each
> | component of the pathname individually as it works them out;
>
> You'd think so, but that doesn't make a lot of sense, as if the code
> is obtaining the path component by component (which is how implementations
> used to work, before the getcwd() interface was invented (and actually
> implemented otherwise than by popen("pwd", "r")) it gets the components
> in the wrong order to write them one at a time as it proceeds - that is,
> the final component comes first, then its parent, ... up to the root.
>
> The only way to start at the beginning would be to do a recursive
> descent through the whole filesystem (as "find" does for example) until
> we happen to encounter the directory that is ".", which would be an
> absurd implementation
That's not the only way. The usual traversal via .., ../.., etc. could
be done, but just storing dev/ino pairs on the way up and then reading
the directories and looking for those stored values on the way down.
Or, a modern implementation could open a file descriptor for each
directory instead of storing dev/ino, and use openat() and fdopendir()
on the way down.
> | Nice try to turn around an argument that actually applies to you, not to
> me.
> | There is nothing in the standard to support your argument.
>
> That is no surprise, and is my point. There is nothing in the standard.
>
> You cannot quote anything to justify your belief of what should be done.
> I cannot because I do not believe there is anything there to quote.
I have already pointed out (not sure if I actually quoted them) the
parts of the standard that make it crystal clear that it requires what
I say it requires. You have subsequently made some futile attempts to
find loopholes, all of which I have shown to be irrelevant or wrong.
As a reminder, these are the relevant parts of the standard:
1. The pwd DESCRIPTION and STDOUT say it writes an absolute pathname
of the current working directory to standard output. (And it is clear
that this is the sole purpose of pwd.)
2. The meaning of "standard output" that applies is the one provided by
XCU 2.7 Redirection:
These numbers are called "file descriptors". The values 0, 1, and
2 have special meaning and conventional uses and are implied by
certain redirection operations; they are referred to as standard
input, standard output, and standard error, respectively.
3. The pwd EXIT STATUS section says that status 0 means "Successful
completion".
Together these things constitute a requirement that pwd only exits
with status 0 if it has successfully written an absolute pathname of
the current working directory to file descriptor 1.
Please don't repeat your previous failed attempts to find a loophole
in this. That would just be a waste of everybody's time.
> | In any case, as I said before, there is no need to involve the standard
> | at all.
>
> But that is what this list is all about. If the discussion is not about
> what the standard says, then it doesn't belong here at all.
Fine. I won't bother to continue that part of the discussion.
> Where something being a bug matters here, is where one (or perhaps
> a couple of) implementation does something different than the others.
> Then if we can describe that as a bug (and certainly if that system's
> implementors admit it) we can simply ignore that, and expect it to get
> fixed. But when (almost) everyone implements the bug, that bug is
> the standard. We don't necessarily need to require it be implemented
> (as these days is being done with sh quoting - some of the more bizarre
> behaviour is unspecified, which allows implementors to fix things
> as much as they can allowing for backward compat issues) but we cannot
> just pretend that there is no bug because we wish it were so.
It would be irresponsible of the standard developers to change the
standard to allow buggy behaviour just because it is common in
implementations, particularly with a bug that is as serious as this
one - utilities failing to diagnose write errors can cause silent data
loss.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
