CANCELED: Austin Group WEBEX +1-408-792-6300 PIN 668 216 233

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:CANCEL
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:665043fc39...@opengroup.org
DTSTAMP:20240530T153338Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240524T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group WEB
 EX +1-408-792-6300 PIN 668 216 233\nDate/Time: 03-Jun-2024 at 11:00 Americ
 a/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengroup.org
 /platform/single_unix_specification/events.php\n\nAll calls are anchored o
 n US time\n\nTopic: Austin Group teleconference\n-
 --\nAudio conference information\n
 ---\n\nYou are invited to a WEBEX 
 meeting. \n
DTSTART;TZID=America/New_York:20240603T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240530T113338Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Austin Group WEBEX +1-408-792-6300 PIN 668 216 233
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

Austin Group WEBEX +1-408-792-6300 PIN 668 216 233

[Single UNIX Specification via austin-group-l at The Open Group]

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:6658989274...@opengroup.org
DTSTAMP:20240530T151739Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240530T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group WEB
 EX +1-408-792-6300 PIN 668 216 233\nDate/Time: 06-Jun-2024 at 11:00 Americ
 a/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengroup.org
 /platform/single_unix_specification/events.php\n\nAll calls are anchored o
 n US time\n\nTopic: Austin Group teleconference\n-
 --\nAudio conference information\n
 ---\n\nYou are invited to a WEBEX 
 meeting. \n
DTSTART;TZID=America/New_York:20240606T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240530T111739Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group WEBEX +1-408-792-6300 PIN 668 216 233
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

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-27 20:04 UTC
== 
Summary:Add preadv() and pwritev()
== 

-- 
 (0006806) steffen (reporter) - 2024-05-27 20:04
 https://austingroupbugs.net/view.php?id=1832#c6806 
-- 
This remark surely belongs to Rich Felker of musl, also because he wrote
the Linux kernel patch, i think (to remember), but i want to add a note ..
or, let me paste parts of a musl commit message instead:

POSIX requires pwrite to honor the explicit file offset where the
write should take place even if the file was opened as O_APPEND.
however, linux historically defined the pwrite syscall family as
honoring O_APPEND. this cannot be changed on the kernel side due to
stability policy, but the addition of the pwritev2 syscall with a
flags argument opened the door to fixing it

this patch changes the pwrite function to first attempt using the
pwritev2 syscall with RWF_NOAPPEND, falling back to using the old
pwrite syscall only after checking that O_APPEND is not set for the
open file. if O_APPEND is set, the operation fails with EOPNOTSUPP,
reflecting that the kernel does not support the correct behavior. this
is an extended error case needed to avoid the wrong behavior that
happened before (writing the data at the wrong location), and is
aligned with the spirit of the POSIX requirement that "An attempt to
perform a pwrite() on a file that is incapable of seeking shall result
in an error."

since the pwritev2 syscall interprets the offset of -1 as a request to
write at the current file offset, it is mapped to a different negative
value that will produce the expected error.

pwritev, though not governed by POSIX at this time, is adjusted to
match pwrite in honoring the offset. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
2024-05-24 21:56 Guy Harris Note Added: 0006800  
2024-05-25 23:10 alanc  Note Added: 0006803  
2024-05-26 00:03 philip-guentherNote Added: 0006804  
2024-05-26 02:43 Guy Harris Note Added: 0006805  
2024-05-27 20:04 steffenNote Added: 0006806  
==

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-26 02:43 UTC
== 
Summary:Add preadv() and pwritev()
== 

-- 
 (0006805) Guy Harris (reporter) - 2024-05-26 02:43
 https://austingroupbugs.net/view.php?id=1832#c6805 
-- 
> and even to have a future direction that they be forbidden from being
cancellation points.

Given that macOS has both "preadv" and "preadv_nocancel" system calls, and
that the GNU libc used in most Linux systems has both "preadv()" and
"__preadv_nocancel()" routines, it's likely that "preadv()" is a
cancellation point on both those OSes, so that might cause problems.

Furthermore, on both those OSes (and most if not all other UN*Xes), "slow"
operation scan occur on special files other than ttys, *and* those special
files might use the seek offset, so there might well be cases where making
pthreadv() not a cancellation point would cause problems, even if it
doesn't cause problems for POSIX-conformant programs.

So I would recommend against that.  Instead, if there is a demand for
non-cancellation-point calls, I would recommend, for a future direction,
that _nocancel versions of calls be added. I don't know why neither macOS
nor GNU(libc)/Linux provide _nocanncel versions of those APIs, but, other
than the namespace pollution issues, it would be trivial to provide them,
at least in those OSes. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
2024-05-24 21:56 Guy Harris Note Added: 0006800  
2024-05-25 23:10 alanc  Note Added: 0006803  
2024-05-26 00:03 philip-guentherNote Added: 0006804  
2024-05-26 02:43 Guy Harris Note Added: 0006805  
==

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-25 23:10 UTC
== 
Summary:Add preadv() and pwritev()
== 

-- 
 (0006803) alanc (reporter) - 2024-05-25 23:10
 https://austingroupbugs.net/view.php?id=1832#c6803 
-- 
If added, preadv() and pwritev() should also be considered to be added to
the list of Cancellation Points in the Thread Cancellation section, to
match readv/writev/pread/pwrite. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
2024-05-24 21:56 Guy Harris Note Added: 0006800  
2024-05-25 23:10 alanc  Note Added: 0006803  
==

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-26 00:03 UTC
== 
Summary:Add preadv() and pwritev()
== 

-- 
 (0006804) philip-guenther (reporter) - 2024-05-26 00:03
 https://austingroupbugs.net/view.php?id=1832#c6804 
-- 
I suggest that preadv/pwritev be documented to MAY be cancellation points
and not MUST be, and even to have a future direction that they be forbidden
from being cancellation points.

The argument is that being a cancellation point is proper for 'slow'
operations, which may block for an arbitrary length of time and where EINTR
would otherwise be an appropriate return-value**.  For read/write those
conditions can occur on sockets, pipes, FIFOs, and ttys...but none of those
are valid for preadv/pwritev!

Yes, this argument applies to pread/pwrite too.  IMHO, I think that the
standard's current requirement for them should be weakened to a MAY as well
with a future direction to completely remove permission for them to be
cancellation points.

Compare this with fcntl() which is only required to be a cancellation point
when the cmd is F_SETLKW, the only 'unbounded blocking' call.  For
pread/pwrite/preadv/pwritev we know they can't exhibit that: why is it
natural for them to be cancellation points?


** Yes, yes, that's not the precise statement of when cancellation would be
expected to be tested, but hopefully the point it clear 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
2024-05-24 21:56 Guy Harris Note Added: 0006800  
2024-05-25 23:10 alanc  Note Added: 0006803  
2024-05-26 00:03 philip-guentherNote Added: 0006804  
==

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-25 23:10 UTC
== 
Summary:Add preadv() and pwritev()
== 

-- 
 (0006803) alanc (reporter) - 2024-05-25 23:10
 https://austingroupbugs.net/view.php?id=1832#c6803 
-- 
If added, preadv() and pwritev() should also be considered to be added to
the list of Cancellation Points in the Thread Cancellation section, to
match readv/writev/pread/pwrite. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
2024-05-24 21:56 Guy Harris Note Added: 0006800  
2024-05-25 23:10 alanc  Note Added: 0006803  
==

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-25 17:12 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006802) kre (reporter) - 2024-05-25 17:12
 https://austingroupbugs.net/view.php?id=1797#c6802 
-- 
Re https://austingroupbugs.net/view.php?id=1797#c6801

there are many ways a conforming C application can set tm_zone.

There cannot be, as C does not have such a field, any attempt to
reference it, in any way, directly or indirectly, would be non-conforming.

  [...] I cited in https://austingroupbugs.net/view.php?id=1797#c6793 all set
tm_zone by calling gmtime

That's not the application setting tm_zone (etc) it is the implementation.
That's allowed, as an extension to the standard.   And while the
application
certainly knows it called gmtime() there is no way (assuming it is a
conforming
C application) that it can deduce from doing so that tm_zone (or tm_gmtoff
which is more relevant for %s) was set by that call.

Such a program should be able to be compiled and run on a system in which
gmtime() does not set those fields, which is perfectly allowable for
implementations of the C standard (it will not be for POSIX applications
after the new standard appears, at least for implementations claiming
conformance).   On such a system the (conforming) program should run and
produce the same results as on a system that happens to set the new
fields.

Furthermore, strftime() needs to work correctly when the struct tm passed
to it has never seen the results of any previous implementation provided
function, and also when it has, but that was in some previous incarnation,
whose use has been completed, and the struct has now been repurposed to
be used just for strftime, with values entirely unrelated to the one it
was previously used for, and only the required values for the format
string used assigned (new) values.

Unless you can provide me with text in the C or POSIX standard which says
that gmtime() localtime() or something equivalent must have generated
(or updated, perhaps via mktime()) any struct tm which is to be passed
to strftime() then the implementation of strftime() simply *must* work
when that has not happened.   "work" means producing the correct result,
which then is obviously also required to be the result if struct tm
with the same required field values had been produced by localtime() or
gmtime() - two different results cannot both be correct (normally anyway).

It makes no difference how common it might be for strftime() to be called
with a struct tm returned from localtime() or gmtime().  Unless there is
a requirement somewhere making that mandatory for applications, then
we cannot assume that it has happened.   Nor can we require that tm_gmtoff
or tm_zone be set by the application, as conforming C applications cannot
do that, and strftime() is a C standard interface (it would be different
were
it one added by POSIX.)

It is irrelevant how many non-conforming, extended, or simply buggy,
implementations, or applications which depend upon them, you can find.
And I'd note, that until earlier this year, your implementation (or ado's
or whoever it was who added strftime()), which I suspect is, or is the
basis of, most real world implementation 

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-24 22:56 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006801) eggert (reporter) - 2024-05-24 22:56
 https://austingroupbugs.net/view.php?id=1797#c6801 
-- 
> A conforming C application cannot set tm_zone as no such
thing exists.

No, there are many ways a conforming C application can set tm_zone. The
several real-world applications I cited in
https://austingroupbugs.net/view.php?id=1797#c6793 all set tm_zone
by calling gmtime, and these apps work fine on GNU/Linux, macOS, z/OS, etc.
This is common practice.

Obviously we disagree about how to interpret POSIX. I find the
overly-strict interpretation unconvincing because (a) significant
real-world implementations have disagreed with that interpretation for
decades, (b) it's easy to find real-world applications that rely on these
implementations' behavior, and (c) it's hard to find real-world
applications that rely on the overly-strict interpretation.

This is not a new issue. What's new is that this lack of clarity or glitch
in the standards is being brought to the standardization bodies' attention. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-15 23:56 eggert New Issue
2024-01-15 23:56 eggert Name  => Paul Eggert 
2024-01-15 23:56 eggert Organization  => UCLA Computer
Science Dept.
2024-01-15 23:56 eggert User Reference=> strftime-%s 
2024-01-15 23:56 eggert Section   => strftime
2024-01-15 23:56 eggert Page Number   => 2136
2024-01-15 23:56 eggert Line Number   => 69836-69837 
2024-01-16 01:29 steffenNote Added: 0006623  
2024-01-16 01:42 steffenNote Added: 0006624  
2024-01-16 01:42 steffenNote Deleted: 0006623
2024-02-01 16:42 nick   Relationship added   related to 0001533  
2024-02-12 16:11 eblake Note Added: 0006651  
2024-02-25 06:50 kreNote Added: 0006677  
2024-02-25 06:54 kreNote Edited: 0006677 
2024-02-26 18:28 eggert Note Added: 0006688  
2024-02-26 19:23 eblake Relationship added   related to 0001816  
2024-02-26 19:32 eblake Note Added: 0006689  
2024-02-26 19:52 eblake Relationship added   child of 0001612
2024-02-26 19:55 eblake Relationship added   child of 169
2024-02-26 20:02 eblake Note Added: 0006690  
2024-02-29 12:10 geoffclare Note Added: 0006691  
2024-02-29 12:15 geoffclare Note Added: 0006692  
2024-02-29 16:19 shware_systems Note Added: 0006693  
2024-03-01 10:09 geoffclare Note Added: 0006698  
2024-03-02 09:02 eggert Note Added: 

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-24 21:48 UTC
== 
Summary:Add preadv() and pwritev()
Description: 
Many implementations offer preadv() and pwritev() interfaces, which are
like
the existing readv() and writev() APIs, except that they use specified 
positions instead of the current file offsets, just like the existing
pread() and pwrite() versions of read() and write().

FreeBSD: 
 - https://man.freebsd.org/cgi/man.cgi?query=preadv
 - https://man.freebsd.org/cgi/man.cgi?query=pwritev
illumos: 
 - https://illumos.org/man/2/preadv
 - https://illumos.org/man/2/pwritev
Linux (GNU libc):  
 - https://man7.org/linux/man-pages/man2/preadv.2.html
NetBSD:
 - https://man.netbsd.org/preadv.2
 - https://man.netbsd.org/pwritev.2
OpenBSD:
 - https://man.openbsd.org/preadv.2
 - https://man.openbsd.org/pwritev.2
Solaris: 
 - (man pages not online yet, just added in 11.4.69 in May 2024)

Known consumers include PostgreSQL and libuv, as discussed in the thread
at
https://twitter.com/MengTangmu/status/1729704220368990235 .

Desired Action: 
Add preadv() and pwritev() to the System Interfaces in Issue 9.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
==

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-24 21:56 UTC
== 
Summary:Add preadv() and pwritev()
== 

-- 
 (0006800) Guy Harris (reporter) - 2024-05-24 21:56
 https://austingroupbugs.net/view.php?id=1832#c6800 
-- 
macOS has it as well (formatted man pages not online at an Apple site, but
their GitHub repository has it in the read(2) man page at
https://opensource.apple.com/source/xnu/xnu-7195.60.75/bsd/man/man2/read.2.auto.html).


Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
2024-05-24 21:56 Guy Harris Note Added: 0006800  
==

[Issue 8 drafts 0001832]: Add preadv() and pwritev()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1832 
== 
Reported By:alanc
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1832
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Alan Coopersmith 
Organization:
User Reference:  
Section:System Interfaces 
Page Number:(page or range of pages) 
Line Number:(Line or range of lines) 
Final Accepted Text: 
== 
Date Submitted: 2024-05-24 21:48 UTC
Last Modified:  2024-05-24 21:48 UTC
== 
Summary:Add preadv() and pwritev()
Description: 
Many implementations offer preadv() and pwritev() interfaces, which are
like
the existing readv() and writev() APIs, except that they use specified 
positions instead of the current file offsets, just like the existing
pread() and pwrite() versions of read() and write().

FreeBSD: 
 - https://man.freebsd.org/cgi/man.cgi?query=preadv
 - https://man.freebsd.org/cgi/man.cgi?query=pwritev
illumos: 
 - https://illumos.org/man/2/preadv
 - https://illumos.org/man/2/pwritev
Linux (GNU libc):  
 - https://man7.org/linux/man-pages/man2/preadv.2.html
NetBSD:
 - https://man.netbsd.org/preadv.2
 - https://man.netbsd.org/pwritev.2
OpenBSD:
 - https://man.openbsd.org/preadv.2
 - https://man.openbsd.org/pwritev.2
Solaris: 
 - (man pages not online yet, just added in 11.4.69 in May 2024)

Known consumers include PostgreSQL and libuv, as discussed in the thread
at
https://twitter.com/MengTangmu/status/1729704220368990235 .

Desired Action: 
Add preadv() and pwritev() to the System Interfaces in Issue 9.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-24 21:48 alanc  New Issue
2024-05-24 21:48 alanc  Name  => Alan Coopersmith
2024-05-24 21:48 alanc  Section   => System Interfaces
2024-05-24 21:48 alanc  Page Number   => (page or range of
pages)
2024-05-24 21:48 alanc  Line Number   => (Line or range of
lines)
==

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-24 21:32 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006799) kre (reporter) - 2024-05-24 21:32
 https://austingroupbugs.net/view.php?id=1797#c6799 
-- 
Re https://austingroupbugs.net/view.php?id=1797#c6798

  But we are talking about what strftime should do with struct tm values
  outside the normal range.

No, we aren't.   strftime() is clear the results are unspecified if the
relevant fields aren't within the normal range(s).   You can do what you
like in that case (but only the relevant fields, when converting %a for
example, it isirrelevant what tn_mday or tm_mon or ... are set to, just
tm_wday).   The same goes for all of the conversions.

  The C standard says that strftime can consult tm_isdst for %Z.

I don't have that one in front of me, but I doubt it says anything
much different than posix says, which is:

  The appropriate characters are determined using the LC_TIME category of
  the current locale and by the values of zero or more members of the
  broken-down time structure pointed to by timeptr, as specified in
  brackets in the description.

What that means is that the specified fields of the struct tm (the
"broken-down time structure") are all that the application needs to
ensure are set in order to perform a specific conversion.   While you're
certainly correct that the implementation can look at other data, that
other data cannot come from the struct, as there's no expectation that
any of that will have been set by the application, and there's no field
in the struct (which would need to be some kind of checksum to detect
changes to other fields made by the application) by which it is possible
to determine that other fields have consistent values with the fields of
interest to the conversion.

But yes, you can certainly use what is in TZ, or anything obtained from
its use, and anything you can get from the LC_TIME locale.

And while:

  tm_zone is an extension to the C standard and the C standard has
  nothing to say about what tm_zone’s contents can or should be.

is certainly true, this conclusion:

  And requiring tm_zone to have sensible contents is not a violation
either:

is incorrect.   A conforming C application cannot set tm_zone as no such
thing exists.   Hence an implementation which is supposed to support
conforming C applications cannot use data from that field, as it has no
way to know if anything is there or not (or anything relevant for sure).
The implementation is certainly allowed to set that field (as in
localtime()
for example), a conforming application will never look there, and so will
never care if it is set or not.

POSIX is intended to support conforming C applications.

And finally:

   When the standard isn’t clear on a matter it’s better to clear it
up;

That's right, but in this case it is clear.   Always has been (even if the
wording was a bit bizarre in some places).  Furthermore, since this affects
C
programs, it should be fixed, if any fixing is needed, by the C standard
first,
not by some end-run performed here. 

Issue History 
Date ModifiedUsername   FieldChange   

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-24 18:59 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006798) eggert (reporter) - 2024-05-24 18:59
 https://austingroupbugs.net/view.php?id=1797#c6798 
-- 
Re Note 0006797:
>   That example doesn’t use gmtime, so it is not completely on point.
>
> But it is exactly on point.

I wrote “on point” because I thought the example was a program in the
wild. But it now appears that it was a test program written to address this
issue. Although I’ve cited several real-world programs using gmtime +
strftime + %s/%z/%Z, we haven’t seen a similar set of programs using
strptime + tm_isdst=-1 + strftime + %s/%z/%Z, so the real-world programs
we’ve seen suggest that strftime should consult tm_gmtoff+tm_zone rather
than global state.


> How is the implementation of strftime() intended to learn whether or
> not its caller used gmtime(), or localtime() or neither of those.

Note 0006794 suggests that strftime use tm_gmtoff (for %s and %z) and
tm_zone (for %Z).


> It doesn't matter that this might be an unusual thing to do

Unfortunately it does matter, because so many real-world implementations
and programs disagree with a reading of the standard that requires strftime
to ignore tm_gmtoff/tm_zone when processing %s/%z/%Z. When the standard
isn’t clear on a matter it’s better to clear it up; and when clearing
it up, it’s better to minimize disruption to common practice; and to do
that, we need to know what common practice is. Although a test app that we
write might be useful for other things, it does not help us discern common
practice in apps.


> it was previously agreed that strftime(%s) and mktime()
> should produce the same result

Yes, when the struct tm values are inside the normal range (that is, when
they could have been produced by localtime).  But we are talking about what
strftime should do with struct tm values outside the normal range.


> Similarly for %z and %Z - both C and POSIX have promised application
> writers that all they need do is set tm_isdst, in an otherwise
completely
> randomly filled (or unfilled) struct tm, and results will be produced.

I don’t see that written down. The C standard says that strftime can
consult tm_isdst for %Z. It does not say that the output of %Z is
completely determined by tm_isdst’s value. Implementations can also look
elsewhere when generating %Z output, and they can impose additional
requirements on the “elsewhere”.

This is true even for POSIX.1-2017, which says that if TZNAME_MAX is 6 and
you set TZ='ABCDEFG0' in the environment, strftime with %Z is allowed to
dump core because the time zone abbreviation is too long. This provision of
POSIX.1-2017 does not violate the C standard, even though it is an
additional requirement above and beyond strftime’s caller setting
tm_isdst. And requiring tm_zone to have sensible contents is not a
violation either: tm_zone is an extension to the C standard and the C
standard has nothing to say about what tm_zone’s contents can or should
be. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-15 23:56 eggert 

Austin Group Status/1003.1 Status Report

[Andrew Josey via austin-group-l at The Open Group]

All
Attached is a brief status report
regards
Andrew
--

Austin Group Status/1003.1 Status ReportAustin-1409 Page 1 of 1
Submitted by Andrew Josey, The Open Group  May 24, 2024

The Austin Common Standards Revision Group (CSRG) is a joint technical
working group established to develop and maintain the core open
systems interfaces that are the POSIX® 1003.1 (and former 1003.2)
standards, ISO/IEC 9945, and the core of the Single UNIX Specification.
The working group brings together the technical experts from ISO
JTC1, IEEE and The Open Group.

The last revision to the 1003.1 standard was published in January 2018.
A new revision has now been approved by The Open Group on
March 21 2024, and by the IEEE on May 21 2024.
We expect this new revision to be published in mid June 2024.

The draft is also undergoing ballot at ISO/IEC and that is
expected to complete at the end of June 2024.

The group meets regularly by teleconference to consider defect
reports and issues on the standard. Minutes are
kept in the Document register at
http://www.opengroup.org/austin/docreg.html .

The group uses an online defect reporting system for maintenance
of the standard, see http://austingroupbugs.net

The next working group meeting is listed at
http://www.opengroup.org/austin/ in the events diary.

Further information on the Austin Group can be obtained at
http://www.opengroup.org/austin/faq.html

Respectfully submitted,
Andrew Josey, The Open Group, 1003.1 Chair


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Minutes of the 23rd May 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of yesterday’s meeting
regards
Andrew
---

Minutes of the 23rd May 2024 TeleconferenceAustin-1408 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 24th May 2024


Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Eric Ackermann, CISPA 
Paul Eggert
Ahmet Acar (joined late)
   
Apologies
Tom Thompson, IEEE
Mark Ziegast, SHware Systems Dev
Eric Blake, Red Hat, The Open Group OR

* General news

There will be no meeting on Monday May 27.

IEEE approval was achieved on May 21 as IEEE Standard 1003.1-2024.
Andrew noted we are preparing the document, which is due
for publication on June 14. We are working on the frontmatter
and participants lists have been posted for final feedback
by close of business Monday May 27.

The ISO/IEC ballot closes on June 28.

* Current Business

1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797


We spent the meeting discussing this item.

The meeting concluded  the following:

>> For %z and %Z, requiring applications to set tm_zone and tm_gmtoff
>>would create a conflict with the C standard. C17 says that the only
>>member used by %z and %Z is tm_isdst.

>There’s no conflict here. C17 does not specify the method used to
>deduce the time zone used for %z and %Z. An implementation is free
>to use whatever screwy method it likes.

Only the C committee can give a definitive answer on what C17
requires here. We cannot finalise new wording for %z and %Z until
we liaise with them. Therefore our next step on this bug should be
to prepare a paper for Nick to submit for consideration by the C
committee.


Items carried forward:

Bug 1818: Add strcasestr() & strcasestr_l() OPEN
https://austingroupbugs.net/view.php?id=1818
Action: Eric B to ask The Open Group if they are willing to sponsor
these functions for Issue 9.

Bug 1824: cp: directories and symlinks OPEN
https://austingroupbugs.net/view.php?id=1824

Action: Eric B to contact the GNU coreutils maintainers to ask for
their input, particularly on the behavior noted in bugnote 6788.


Bug 1831: how do you get the timestamp resolution of a symlink? OPEN
https://austingroupbugs.net/view.php?id=1831

Action: EricB to ask The Open Group to sponsor this change.


Next Steps 
--
Reminder: Mon 2024-05-27 No meeting

The next call is on:
  Thu 2024-05-30 (WEBEX meeting - general bugs)
  Mon 2024-06-03 (WEBEX meeting - general bugs)

  
The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Austin Group WEBEX +1-408-792-6300 PIN 668 216 233

[Single UNIX Specification via austin-group-l at The Open Group]

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:665043fc39...@opengroup.org
DTSTAMP:20240524T073836Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240524T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group WEB
 EX +1-408-792-6300 PIN 668 216 233\nDate/Time: 03-Jun-2024 at 11:00 Americ
 a/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengroup.org
 /platform/single_unix_specification/events.php\n\nAll calls are anchored o
 n US time\n\nTopic: Austin Group teleconference\n-
 --\nAudio conference information\n
 ---\n\nYou are invited to a WEBEX 
 meeting. \n
DTSTART;TZID=America/New_York:20240603T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240524T033836Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group WEBEX +1-408-792-6300 PIN 668 216 233
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

Austin Group WEBEX +1-408-792-6300 PIN 668 216 233

[Single UNIX Specification via austin-group-l at The Open Group]

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:66504385df...@opengroup.org
DTSTAMP:20240524T073638Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240524T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group WEB
 EX +1-408-792-6300 PIN 668 216 233\nDate/Time: 30-May-2024 at 11:00 Americ
 a/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengroup.org
 /platform/single_unix_specification/events.php\n\nAll calls are anchored o
 n US time\n\nTopic: Austin Group teleconference\n-
 --\nAudio conference information\n
 ---\n\nYou are invited to a WEBEX 
 meeting. \n
DTSTART;TZID=America/New_York:20240530T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240524T033638Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group WEBEX +1-408-792-6300 PIN 668 216 233
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

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-23 16:57 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006797) kre (reporter) - 2024-05-23 16:57
 https://austingroupbugs.net/view.php?id=1797#c6797 
-- 
Re https://austingroupbugs.net/view.php?id=1797#c6793 and
https://austingroupbugs.net/view.php?id=1797#c6794

I really believe that those notes show a lack of understanding of the
issue here.

The following comment in https://austingroupbugs.net/view.php?id=1797#c6793 
demonstrates that:

  > Here's one, with all of the error handling, #includes, etc, removed to
  > save space here (they exist in the real thing, naturally):

  That example doesn’t use gmtime, so it is not completely on point.

But it is exactly on point.   How is the implementation of strftime()
intended to learn whether or not its caller used gmtime(), or localtime()
or neither of those.

Let me give that example again, with one more minor addition, to make
the underlying difficulty more obvious:


main(int argc, char **argv)
{
time_t now;
struct tm tm;
char *p;
int i;
char buf[64];

(void)time();/* or fill in "now" however you like */
tm = *gmtime();
/* do something with the tm, doesn't matter what */


p = strptime(argv[1], "%Y-%m-%d %H:%M:%S", );
tm.tm_isdst = -1;

for (i = 2; i < argc; i++) {
setenv("TZ", argv[i], 1);
tzset();
strftime(buf, sizeof buf, "%s", );
printf("%s %s\n", buf, argv[i]);
}
exit(0);
}

nb: same caveat about missing error handling, #includes, etc, as when
the earlier version of this was in
https://austingroupbugs.net/view.php?id=1797#c6701

Now the program has called gmtime() - that call just happens to be 100%
irrelevant to the calls of strftime() (using a struct tm which had the
results from gmtime() copied into it, some time in the past).   How does
your implementation propose to generate sensible results here.

Even without the call to gmtime() there, how does your implementation
propose to tell whether there was one or not?

It doesn't matter that this might be an unusual thing to do, the fields
that the strptime() call filled in (along with tm_isdst which is set
separately) are all that is required for mktime() to work on the data,
and I think it was previously agreed that strftime(%s) and mktime()
should produce the same result (one as a string, the other as a time_t
but that's immaterial).That's certainly how it has always been
specified.   Applications are entitled to operate that way.

Similarly for %z and %Z - both C and POSIX have promised application
writers that all they need do is set tm_isdst, in an otherwise completely
randomly filled (or unfilled) struct tm, and results will be produced.

Certainly the standards do not, and should not, tell the implementers how
to generate the results, but those implementers need to make things work
when the application does the bare minimum required of it by the
standards,
regardless of how many other applications do things differently.

We simply cannot ignore what has been promised before, and change the
state of the world, requiring 

[Issue 8 drafts 0001774]: Support ' as a format specifier flag character in utilities

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1774 
== 
Reported By:eblake
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1774
Category:   Base Definitions and Headers
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: New
Name:   Eric Blake 
Organization:   Red Hat 
User Reference: ebb.file format 
Section:XBD 5 File Format Notation 
Page Number:114 
Line Number:3581 
Final Accepted Text: 
== 
Date Submitted: 2023-08-31 17:45 UTC
Last Modified:  2024-05-23 14:38 UTC
== 
Summary:Support '  as a format specifier flag
character in utilities
==
Relationships   ID  Summary
--
related to  0001771 support or reserve %q as printf-utility...
== 

-- 
 (0006796) geoffclare (manager) - 2024-05-23 14:38
 https://austingroupbugs.net/view.php?id=1774#c6796 
-- 
I searched the (Issue 8) troff source for cross-references to File Format
Notation and the only ones where it is used to specify how a utility
processes a format string are in:

awk printf statement
pax -o listopt=format
printf utility

Since printf and awk have already been mentioned, the only new one to
consider is pax.
I could see it being a useful feature in pax for things like:

pax -v -o listopt=" %'(size)i " 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-08-31 17:45 eblake New Issue
2023-08-31 17:45 eblake Name  => Eric Blake  
2023-08-31 17:45 eblake Organization  => Red Hat 
2023-08-31 17:45 eblake User Reference=> ebb.file format 
2023-08-31 17:45 eblake Section   => XBD 5 File Format
Notation
2023-08-31 17:45 eblake Page Number   => 114 
2023-08-31 17:45 eblake Line Number   => 3581
2023-08-31 17:46 eblake Relationship added   related to 0001771  
2024-05-23 14:38 geoffclare Note Added: 0006796  
==

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-23 08:07 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006794) eggert (reporter) - 2024-05-23 08:07
 https://www.austingroupbugs.net/view.php?id=1797#c6794 
-- 
Although the resolution proposed in Note: 0006691 has a lot to like, we
need to do better with %s, %z, and %Z, as discussed in my previous comment.
One thing that’s not clearly nailed down is that the implementation
should be consistent in this area. That is, whatever it does for %s should
be consistent with what it does for %z, and likewise for %Z. This is a
“should” not a “must” because not every implementation is
consistent, but intuitively it makes sense that the three formats should
expand to consistent output.


Interpretation response

The standard states that when the input is in the normal range the
strftime() %s conversion calculates the number of seconds since the Epoch
as described for mktime(), and conforming implementations must conform to
this. However, concerns have been raised about this which are being
referred to the sponsor.

Rationale:
-
In previous editions of POSIX, struct tm lacked tm_gmtoff and tm_zone
members, so strftime needed to inspect global state to process %z and %Z.
The current version allows strftime to instead inspect tm_gmtoff for %z,
and tm_zone for %Z, as is common practice. For consistency it also allows
strftime to inspect tm_gmtoff to process %s, a newly-required format.

A strftime that inspects tm_gmtoff and tm_zone works better with
applications that use geographical timezones, or that fill in struct tm
members by calling gmtime or equivalent. Conversely, a strftime that
inspects global state is more compatible with previous editions of POSIX
when programs use the second TZ format in XBD Section 8.3 and fill in
struct tm members individually without calling localtime or equivalent. A
strftime implementation can do both: that is, it can inspect global state
when the second TZ format is used, and use tm_gmtoff and tm_zone when a
geographical timezone is used.

This edition of the standard does not say whether the abovementioned global
state consists of the contents of the variables tzname and timezone, or
some other part of the system state that user code cannot modify directly.
Modifying tzname and timezone therefore might (but might not) affect the
global state that in turn might affect strftime’s behavior with %s, %z,
and %Z, or might not if strftime inspects tm_gmtoff and tm_zone instead.

Regardless of implementation method, implementations should process the
conversion specifications %s, %z, and %Z consistently. For example, if
strftime uses tm_gmtoff to process %z, it should also use tm_gmtoff to
process %s and should use tm_zone to process %Z. Conversely, if strftime
uses global state to determine one of the the three conversion
specifications, it should use the same global state to determine the other
two.


Notes to the Editor (not part of this interpretation):
---
Using draft 4.0 line numbering:

On page 452 lines 15762-15763 section XBD , add CX shading to the
lines for tm_gmtoff and tm_zone.

On page 

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-23 10:47 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006795) geoffclare (manager) - 2024-05-23 10:47
 https://austingroupbugs.net/view.php?id=1797#c6795 
-- 
>> For %z and %Z, requiring applications to set tm_zone and tm_gmtoff would
create a conflict with the C standard. C17 says that the only member used
by %z and %Z is tm_isdst.

>There’s no conflict here. C17 does not specify the method used to deduce
the time zone used for %z and %Z. An implementation is free to use whatever
screwy method it likes.

Only the C committee can give a definitive answer on what C17 requires
here. We cannot finalise new wording for %z and %Z until we liaise with
them. Therefore our next step on this bug should be to prepare a paper for
Nick to submit for consideration by the C committee. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-15 23:56 eggert New Issue
2024-01-15 23:56 eggert Name  => Paul Eggert 
2024-01-15 23:56 eggert Organization  => UCLA Computer
Science Dept.
2024-01-15 23:56 eggert User Reference=> strftime-%s 
2024-01-15 23:56 eggert Section   => strftime
2024-01-15 23:56 eggert Page Number   => 2136
2024-01-15 23:56 eggert Line Number   => 69836-69837 
2024-01-16 01:29 steffenNote Added: 0006623  
2024-01-16 01:42 steffenNote Added: 0006624  
2024-01-16 01:42 steffenNote Deleted: 0006623
2024-02-01 16:42 nick   Relationship added   related to 0001533  
2024-02-12 16:11 eblake Note Added: 0006651  
2024-02-25 06:50 kreNote Added: 0006677  
2024-02-25 06:54 kreNote Edited: 0006677 
2024-02-26 18:28 eggert Note Added: 0006688  
2024-02-26 19:23 eblake Relationship added   related to 0001816  
2024-02-26 19:32 eblake Note Added: 0006689  
2024-02-26 19:52 eblake Relationship added   child of 0001612
2024-02-26 19:55 eblake Relationship added   child of 169
2024-02-26 20:02 eblake Note Added: 0006690  
2024-02-29 12:10 geoffclare Note Added: 0006691  
2024-02-29 12:15 geoffclare Note Added: 0006692  
2024-02-29 16:19 shware_systems Note Added: 0006693  
2024-03-01 10:09 geoffclare Note Added: 0006698  
2024-03-02 09:02 eggert Note Added: 0006700  
2024-03-03 01:20 kreNote Added: 0006701  
2024-03-07 10:44 geoffclare Note Added: 0006706  
2024-03-07 11:04 geoffclare Note Added: 0006707  
2024-03-11 09:55 

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-05-23 08:04 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
==
Relationships   ID  Summary
--
related to  0001533 struct tm: add tm_gmtoff (and tm_zone) ...
related to  0001816 daylight, timezone, tzname do not work ...
child of0001612 XSH strftime() new (I8) %s conversion r...
child of169 date utility needs ``%s''
== 

-- 
 (0006793) eggert (reporter) - 2024-05-23 08:04
 https://www.austingroupbugs.net/view.php?id=1797#c6793 
-- 
Re Note: 0006701
> The code in that report was simply wrong, even
> with the wording in Note: 0006689 it would still be broken.

That code is unportable, not “wrong” or “broken”. The wording in
Note: 0006689 would let implementations do what the code’s author
intended. For this use case, that’s better than requiring implementations
to not follow the intent. I continue to be skeptical that typical
developers would expect strftime(buf, size, "%F %T %Z", gmtime()) to do
anything other than output a string representing UTC.


>   In contrast, we don’t know of programs that would benefit from the
>   resolution in Note: 0006691, and these programs are less plausible.
>
> Here's one, with all of the error handling, #includes, etc, removed to
> save space here (they exist in the real thing, naturally):

That example doesn’t use gmtime, so it is not completely on point.

I accept that one can contrive programs that prefer the other
interpretation. However, I continue to maintain that the vast majority of
programs assume the interpretations used by TZDB for %z and %Z.

To check this, I did a GitHub code search today with the query “strftime
gmtime path:*.c”. Most matches were irrelevant, because the output of
gmtime was not passed to strftime, or because the strftime format string
did not use %s, %z, or %Z. In a few matches it was hard to see what’s
going on, so I ignored them. However, all the relevant matches I found
(listed below) preferred the proposed interpretation: that is, they
expected strftime to format the gmtime output as UTC, not as local time. In
many cases this was because they let the user specify an arbitrary strftime
format to be applied to the result of gmtime, and users would naturally
expect gmtime to output GMT aka UTC.

Here are the matches I found:

https://github.com/davidmoreno/onion/blob/de8ea938342b36c28024fd8393ebc27b8442a161/src/onion/shortcuts.c#L350
https://github.com/erlang/otp/blob/945c940f6bc6c0bcb026cdc6ae8f3ce358e859bb/erts/etc/unix/run_erl.c#L583
https://github.com/esnet/iperf/blob/93c60bf2ea8aa52e98399223ec04a95f65f00f7b/src/iperf_api.c#L948
https://github.com/jonas/tig/blob/587a59abab3f2ebe7612bc69f44c22df570b2ee3/src/util.c#L208
https://github.com/openwall/john/blob/9f913a734055aae2606c68851a5a16b0d50a2060/src/logger.c#L324
https://github.com/RediSearch/RediSearch/blob/10261d2f93e77a3d1118ccded01fb4fa0e1c9cca/src/aggregate/functions/date.c#L36
https://github.com/RMerl/asuswrt-merlin.ng/blob/466f5aee9e274971480a19497573c4264f865019/release/src/router/aws-iot/src/time_util.c#L56
https://github.com/RMerl/asuswrt-merlin.ng/blob/466f5aee9e274971480a19497573c4264f865019/release/src/router/rc/conn_diag_log.c#L334
https://github.com/root-project/root/blob/333f042a16525e746da4ec56c3a5a3ed79ceb677/tutorials/graphs/timeonaxis3.C#L25
https://github.com/cheat-engine/cheat-engine/blob/54f90a22bfc9d4981f414a7917d70d3d17f190e5/lua/src/loslib.c#L129


> The reason that strftime() needs in range values in
> general, is not because 

Approvals and participants listings in the front matter

[Andrew Josey via austin-group-l at The Open Group]

Dear all

We are pleased to announce that IEEE has approved the draft as the 2024
edition of the 1003.1 standard. The document has also been approved at The Open 
Group.

We are now completing the document for publication. In the document front 
matter we list the participants.

We have two lists of participants from the Austin Group:

Austin Group participants: (people who sent an email to austin-group-l since 
mid 2016 - i.e. after TC2)

Austin Group reviewers: (people who submitted Mantis bugs that were applied in 
Issue 8)

These lists are available to review at 

https://www.opengroup.org/austin/restricted/participants/  (login required)

Please review (check spelling, accents etc.) and feed comments back asap and no 
later than Monday May 27.

If you feel you are missing please contact me directly
regards
Andrew

Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Minutes of the 20th May 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of the Monday call this week.

Note that since the call we received formal news of the approval
of the document by IEEE:

"I am pleased to inform you that P1003.1 was approved as a revised standard by 
the IEEE SA Standards Board on 20 May 2024."
regards
Andrew


Minutes of the 20th May 2024 TeleconferenceAustin-1406 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 22nd May 2024


Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group
Geoff Clare, The Open Group
   
Apologies
Tom Thompson, IEEE
Mark Ziegast, SHware Systems Dev
Eric Ackermann, CISPA 
Eric Blake, Red Hat, The Open Group OR (joining late)

* General news

There will be no meeting on Monday May 27.

The approval vote on 1003.1 closes today (after the meeting
we received notice of approval as IEEE Standard 1003.1-2024)

The ISO/IEC ballot closes on June 28.

* Current Business

1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797


We expect to continue this item this coming Thursday
(Paul has confirmed availability).


Bug 1818: Add strcasestr() & strcasestr_l() OPEN
https://austingroupbugs.net/view.php?id=1818
Action: Eric B to ask The Open Group if they are willing to sponsor
these functions for Issue 9.

Bug 1822: Define splitting using a null field separator Accepted as Marked
https://austingroupbugs.net/view.php?id=1822

This item is tagged for Issue 9.

Page and line numbers are for issue 8 draft 4.1.
On P2617, L85671 section awk (EXTENDED DESCRIPTION) change:
If FS is a null string, the behavior is unspecified.
to:
If FS is a null string, each character shall become a separate field.

We started on this item. Notes are in the etherpad.  We will continue
on this item next time.

Bug 1824: cp: directories and symlinks OPEN
https://austingroupbugs.net/view.php?id=1824

Action: Eric B to contact the GNU coreutils maintainers to ask for
their input, particularly on the behavior noted in bugnote 6788.

Bug 1825: Does releasing a reader lock carries a "release" memory order 
semantic?  Withdrawn
https://austingroupbugs.net/view.php?id=1825

Withdrawn by the submitter.

Bug 1826: du: space used between  and , while common 
implementations use tab Rejected
https://austingroupbugs.net/view.php?id=1826


Bug 1827: Standardize gzip(1) cli interface instead of adding it to compress(1) 
Rejected
https://austingroupbugs.net/view.php?id=1827

Bug 1041 was resolved more than 7 years ago and had been included
in draft versions of the standard for more than 4 years before bug
1827 was submitted.  Filing a bug to reverse this after the IEEE
and The Open Group ballots have been completed and while the ISO
ballot on the current version of the standard is in its final stage
is way too late to make the requested changes.  Furthermore, these
issues were discussed before the changes were approved seven years
ago and the standard developers believed then and still believe
that including the changes to compress was better than adding several
other sets of compression utilities.  Therefore, this bug is rejected.


Bug 1828: Rationale is out of date  Accepted
https://austingroupbugs.net/view.php?id=1828

This item is tagged for TC1-2024

Bug 1829: symlink() and terminating null bytes Accepted as Marked
https://austingroupbugs.net/view.php?id=1829

This item is tagged for TC1-2024

Make the changes suggested in the Desired Action and in Note: 0006776. 

Bug 1830: off-by-one error regarding offset maximum Accepted as Marked
https://austingroupbugs.net/view.php?id=1830

This item is tagged for TC1-2024

Change:
For regular files, no data transfer shall occur past the offset
maximum established in the open file description associated
with fildes.
to:
For regular files, no data shall be written at positions greater
than or equal to the offset maximum established in the open
file description associated with fildes. If the starting position
is greater than or equal to the offset maximum (and nbyte is
greater than 0), the request shall fail; otherwise, only as
many bytes as there is room for shall be written.


Bug 1831: how do you get the timestamp resolution of a symlink? OPEN
https://austingroupbugs.net/view.php?id=1831

Action: EricB to ask The Open Group to sponsor this change.

Closing 786 as a duplicate of this, since this is more up to date
and refers to an implementation that is expected to exist by the
time this is standardized.

Bug 786: pathconfat() is missing Dup of 1831
https://austingroupbugs.net/view.php?id=786
Closed, duplicate of 1831.


Next Steps 
--

The next call is on:
  Thu 2024-05-23 (WEBEX meeting - general bugs)
  Mon 2024-05-27 No meeting
  Thu 2024-05-30 (WEBEX meeting - general bugs)

Apologies in Advance:
Eric Blake 2024-05-20, 2024-05-

回复: Query regarding bug 1825 over certain underspecified memory semantic.

[Niu Danny via austin-group-l at The Open Group]

Ah, my idiocracy again.

I just realized yield/sleep are always preceeded by a 
mutex release or followed by a mutex acquire in
multi-threaded applications in older systems.

Thanks anyway.


发件人: austin-group-l@opengroup.org  代表 Geoff Clare 
via austin-group-l at The Open Group 
发送时间: 2024年5月20日 23:45
收件人: austin-group-l@opengroup.org
主题: Re: Query regarding bug 1825 over certain underspecified memory semantic.

Niu Danny wrote, on 20 May 2024:
>
> I see the bug's still not closed. Would standard maintainers disclose
> if there's still discussion over this issue?

By coincidence we reached that bug in today's teleconference, and
have processed it as withdrawn based on your comments in the bug.

> Another issue I thought of, but refrained from bringing onto the issue 
> tracker,
> is that in older (not necessarily Unix/POSIX) systems, when there's no
> condition variable, threads would wait for predicates to become true by
> yielding, or sleeping if expiration is needed. Should yield/sleep synchronize
> memory? What's the group's opinion on this?

My personal take is that I only see yield as affecting scheduling.
I.e. it's purely a way for the thread to ask the scheduler to stop
running it earlier than it otherwise would.  So I would not expect
its effect on memory to be any different than if the scheduler
happened to stop running the thread at that point in the code.

--
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

[1003.1(2008)/Issue 7 0000786]: pathconfat() is missing

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been CLOSED. 
== 
https://www.austingroupbugs.net/view.php?id=786 
== 
Reported By:joerg
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   786
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Jörg Schilling 
Organization:   FOKUS Fraunhofer 
User Reference:  
Section:3 System Interfaces 
Page Number:893 
Line Number:29895-29905 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Duplicate
Duplicate:  0
Fixed in Version:   
== 
Date Submitted: 2013-11-04 21:57 UTC
Last Modified:  2024-05-20 16:25 UTC
== 
Summary:pathconfat() is missing
==
Relationships   ID  Summary
--
duplicate of0001831 how do you get the timestamp resolution...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-11-04 21:57 joerg  New Issue
2013-11-04 21:57 joerg  Status   New => Under Review 
2013-11-04 21:57 joerg  Assigned To   => ajosey  
2013-11-04 21:57 joerg  Name  => Jörg Schilling 
2013-11-04 21:57 joerg  Organization  => FOKUS Fraunhofer
2013-11-04 21:57 joerg  Section   => 3 System Interfaces
2013-11-04 21:57 joerg  Page Number   => 893 
2013-11-04 21:57 joerg  Line Number   => 29895-29905 
2013-11-04 22:12 eblake Note Added: 0001957  
2013-11-05 08:34 shware_systems Note Added: 0001958  
2013-11-05 08:35 shware_systems Note Edited: 0001958 
2013-11-07 14:16 joerg  Note Added: 0001966  
2013-11-07 16:30 dalias Note Added: 0001967  
2013-12-19 16:57 eblake Interp Status => --- 
2013-12-19 16:57 eblake Note Added: 0002086  
2013-12-19 16:57 eblake Resolution   Open => Future
Enhancement
2013-12-19 17:02 eblake Note Edited: 0002086 
2014-01-08 14:23 shware_systems Note Added: 0002095  
2015-09-11 15:47 geoffclare Note Added: 0002827  
2024-05-20 16:21 nick   Relationship added   related to 0001831  
2024-05-20 16:22 nick   Relationship replacedduplicate of 0001831
2024-05-20 16:25 Don Cragun Status   Under Review => Closed
2024-05-20 16:25 Don Cragun Resolution   Future Enhancement =>
Duplicate
==

[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1831 
== 
Reported By:philip-guenther
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1831
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Philip Guenther 
Organization:   OpenBSD 
User Reference:  
Section:pathconf 
Page Number:902-907 
Line Number:30519 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-15 08:10 UTC
Last Modified:  2024-05-20 16:25 UTC
== 
Summary:how do you get the timestamp resolution of a
symlink?
==
Relationships   ID  Summary
--
has duplicate   786 pathconfat() is missing
== 

-- 
 (0006792) nick (manager) - 2024-05-20 16:25
 https://austingroupbugs.net/view.php?id=1831#c6792 
-- 
Closing 786 as a duplicate of this, since this is more up to date and
refers to an  implementation that is expected to exist by the time this is
standardized. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-15 08:10 philip-guentherNew Issue
2024-05-15 08:10 philip-guentherName  => Philip Guenther 
2024-05-15 08:10 philip-guentherOrganization  => OpenBSD 
2024-05-15 08:10 philip-guentherSection   => pathconf
2024-05-15 08:10 philip-guentherPage Number   => 902-907 
2024-05-15 08:10 philip-guentherLine Number   => 30519   
2024-05-15 17:11 philip-guentherNote Added: 0006780  
2024-05-18 05:57 philip-guentherNote Added: 0006783  
2024-05-20 16:21 nick   Relationship added   related to 786  
2024-05-20 16:22 nick   Relationship replacedhas duplicate 786
2024-05-20 16:25 nick   Note Added: 0006792  
==

[1003.1(2008)/Issue 7 0000786]: pathconfat() is missing

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 0001831. 
== 
https://austingroupbugs.net/view.php?id=786 
== 
Reported By:joerg
Assigned To:ajosey
== 
Project:1003.1(2008)/Issue 7
Issue ID:   786
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Jörg Schilling 
Organization:   FOKUS Fraunhofer 
User Reference:  
Section:3 System Interfaces 
Page Number:893 
Line Number:29895-29905 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2013-11-04 21:57 UTC
Last Modified:  2015-09-11 15:47 UTC
== 
Summary:pathconfat() is missing
==
Relationships   ID  Summary
--
related to  0001831 how do you get the timestamp resolution...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-11-04 21:57 joerg  New Issue
2013-11-04 21:57 joerg  Status   New => Under Review 
2013-11-04 21:57 joerg  Assigned To   => ajosey  
2013-11-04 21:57 joerg  Name  => Jörg Schilling 
2013-11-04 21:57 joerg  Organization  => FOKUS Fraunhofer
2013-11-04 21:57 joerg  Section   => 3 System Interfaces
2013-11-04 21:57 joerg  Page Number   => 893 
2013-11-04 21:57 joerg  Line Number   => 29895-29905 
2013-11-04 22:12 eblake Note Added: 0001957  
2013-11-05 08:34 shware_systems Note Added: 0001958  
2013-11-05 08:35 shware_systems Note Edited: 0001958 
2013-11-07 14:16 joerg  Note Added: 0001966  
2013-11-07 16:30 dalias Note Added: 0001967  
2013-12-19 16:57 eblake Interp Status => --- 
2013-12-19 16:57 eblake Note Added: 0002086  
2013-12-19 16:57 eblake Resolution   Open => Future
Enhancement
2013-12-19 17:02 eblake Note Edited: 0002086 
2014-01-08 14:23 shware_systems Note Added: 0002095  
2015-09-11 15:47 geoffclare Note Added: 0002827  
2024-05-20 16:21 nick   Relationship added   related to 0001831  
==

[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 786. 
== 
https://austingroupbugs.net/view.php?id=1831 
== 
Reported By:philip-guenther
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1831
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Philip Guenther 
Organization:   OpenBSD 
User Reference:  
Section:pathconf 
Page Number:902-907 
Line Number:30519 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-15 08:10 UTC
Last Modified:  2024-05-20 16:21 UTC
== 
Summary:how do you get the timestamp resolution of a
symlink?
==
Relationships   ID  Summary
--
related to  786 pathconfat() is missing
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-15 08:10 philip-guentherNew Issue
2024-05-15 08:10 philip-guentherName  => Philip Guenther 
2024-05-15 08:10 philip-guentherOrganization  => OpenBSD 
2024-05-15 08:10 philip-guentherSection   => pathconf
2024-05-15 08:10 philip-guentherPage Number   => 902-907 
2024-05-15 08:10 philip-guentherLine Number   => 30519   
2024-05-15 17:11 philip-guentherNote Added: 0006780  
2024-05-18 05:57 philip-guentherNote Added: 0006783  
2024-05-20 16:21 nick   Relationship added   related to 786  
==

[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://www.austingroupbugs.net/view.php?id=1829 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1829
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:symlink() 
Page Number:2095 
Line Number:67093 
Interp Status:  --- 
Final Accepted Text:See
https://www.austingroupbugs.net/view.php?id=1829#c6791. 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2024-05-02 16:48 UTC
Last Modified:  2024-05-20 16:06 UTC
== 
Summary:symlink() and terminating null bytes
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-02 16:48 geoffclare New Issue
2024-05-02 16:48 geoffclare Name  => Geoff Clare 
2024-05-02 16:48 geoffclare Organization  => The Open Group  
2024-05-02 16:48 geoffclare Section   => symlink()   
2024-05-02 16:48 geoffclare Page Number   => 2095
2024-05-02 16:48 geoffclare Line Number   => 67093   
2024-05-02 16:48 geoffclare Interp Status => --- 
2024-05-02 16:52 geoffclare Note Added: 0006776  
2024-05-20 16:05 Don Cragun Note Added: 0006791  
2024-05-20 16:06 Don Cragun Final Accepted Text   => See
https://www.austingroupbugs.net/view.php?id=1829#c6791.
2024-05-20 16:06 Don Cragun Status   New => Resolved 
2024-05-20 16:06 Don Cragun Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1829 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1829
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:symlink() 
Page Number:2095 
Line Number:67093 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-02 16:48 UTC
Last Modified:  2024-05-20 16:05 UTC
== 
Summary:symlink() and terminating null bytes
== 

-- 
 (0006791) Don Cragun (manager) - 2024-05-20 16:05
 https://www.austingroupbugs.net/view.php?id=1829#c6791 
-- 
Make the changes suggested in the Desired Action and in
https://www.austingroupbugs.net/view.php?id=1829#c6776. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-02 16:48 geoffclare New Issue
2024-05-02 16:48 geoffclare Name  => Geoff Clare 
2024-05-02 16:48 geoffclare Organization  => The Open Group  
2024-05-02 16:48 geoffclare Section   => symlink()   
2024-05-02 16:48 geoffclare Page Number   => 2095
2024-05-02 16:48 geoffclare Line Number   => 67093   
2024-05-02 16:48 geoffclare Interp Status => --- 
2024-05-02 16:52 geoffclare Note Added: 0006776  
2024-05-20 16:05 Don Cragun Note Added: 0006791  
==

[1003.1(2016/18)/Issue7+TC2 0001828]: Rationale is out of date

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://www.austingroupbugs.net/view.php?id=1828 
== 
Reported By:nick
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1828
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   low
Status: Resolved
Name:   Nick Stoughton 
Organization:
User Reference:  
Section:sys/stat.h 
Page Number:395 
Line Number:13468 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Accepted
Fixed in Version:   
== 
Date Submitted: 2024-05-02 16:23 UTC
Last Modified:  2024-05-20 15:59 UTC
== 
Summary:Rationale is out of date
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-02 16:23 nick   New Issue
2024-05-02 16:23 nick   Name  => Nick Stoughton  
2024-05-02 16:23 nick   Section   => sys/stat.h  
2024-05-02 16:23 nick   Page Number   => 395 
2024-05-02 16:23 nick   Line Number   => 13468   
2024-05-02 16:23 nick   Interp Status => --- 
2024-05-20 15:59 Don Cragun Status   New => Resolved 
2024-05-20 15:59 Don Cragun Resolution   Open => Accepted
==

[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been CLOSED. 
== 
https://austingroupbugs.net/view.php?id=1825 
== 
Reported By:dannyniu
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1825
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: Closed
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:pthread_rwlock_* 
Page Number:1787-1804 
Line Number:59262-59785 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2024-04-02 06:44 UTC
Last Modified:  2024-05-20 15:26 UTC
== 
Summary:Does releasing a reader lock carries a "release"
memory order semantic?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-04-02 06:44 dannyniu   New Issue
2024-04-02 06:44 dannyniu   Name  => DannyNiu/NJF
2024-04-02 06:44 dannyniu   Organization  => 
2024-04-02 06:44 dannyniu   Section   => pthread_rwlock_*
2024-04-02 06:44 dannyniu   Page Number   => 1787-1804   
2024-04-02 06:44 dannyniu   Line Number   => 59262-59785 
2024-04-02 15:28 geoffclare Note Added: 0006733  
2024-04-03 04:11 dannyniu   Note Added: 0006735  
2024-04-04 09:09 geoffclare Note Added: 0006736  
2024-04-04 14:34 dannyniu   Note Added: 0006738  
2024-05-20 15:26 nick   Status   New => Closed   
2024-05-20 15:26 nick   Resolution   Open => Withdrawn   
==

[Issue 8 drafts 0001827]: Standardize gzip(1) cli interface instead of adding it to compress(1)

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been CLOSED. 
== 
https://www.austingroupbugs.net/view.php?id=1827 
== 
Reported By:nrk
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1827
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Objection
Priority:   normal
Status: Closed
Name:   NRK 
Organization:
User Reference:  
Section:compress(1) utility 
Page Number:n/a 
Line Number:n/a 
Final Accepted Text: 
Resolution: Rejected
Fixed in Version:   
== 
Date Submitted: 2024-04-15 03:23 UTC
Last Modified:  2024-05-20 15:55 UTC
== 
Summary:Standardize gzip(1) cli interface instead of adding
it to compress(1)
== 

-- 
 (0006790) Don Cragun (manager) - 2024-05-20 15:55
 https://www.austingroupbugs.net/view.php?id=1827#c6790 
-- 
Bug 1041 was resolved more than 7 years ago and had been included in draft
versions of the standard for more than 4 years before bug 1827 was
submitted.  Filing a bug to reverse this after the IEEE and The Open Group
ballots have been completed and while the ISO ballot on the current version
of the standard is in its final stage is way too late to make the requested
changes.  Furthermore, these issues were discussed before the changes were
approved seven years ago and the standard developers believed then and
still believe that including the changes to compress was better than adding
several other sets of compression utilities.  Therefore, this bug is
rejected. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-04-15 03:23 nrkNew Issue
2024-04-15 03:23 nrkName  => NRK 
2024-04-15 03:23 nrkSection   => compress(1) utility
2024-04-15 03:23 nrkPage Number   => n/a 
2024-04-15 03:23 nrkLine Number   => n/a 
2024-04-15 03:24 nrkIssue Monitored: nrk 
2024-04-16 05:57 dannyniu   Note Added: 0006752  
2024-04-16 05:58 dannyniu   Note Edited: 0006752 
2024-04-16 18:39 steffenNote Added: 0006753  
2024-04-16 22:51 nrkNote Added: 0006754  
2024-04-16 23:03 nrkNote Added: 0006755  
2024-04-16 23:32 oguzismailuysalNote Added: 0006756  
2024-04-17 00:10 steffenNote Added: 0006757  
2024-04-17 00:32 nrkNote Added: 0006758  
2024-04-17 01:36 larryv Note Added: 0006759  
2024-04-17 06:16 oguzismailuysalNote Added: 0006760  
2024-04-17 06:18 oguzismailuysalNote Edited: 0006760 
2024-04-17 06:19 oguzismailuysalNote Edited: 0006760 
2024-04-17 07:47 nrkNote Added: 0006761  
2024-04-17 11:03 oguzismailuysalNote Added: 0006762  
2024-04-17 18:01 steffenNote Added: 0006763  
2024-05-20 15:55 Don Cragun Note Added: 0006790  
2024-05-20 15:55 Don Cragun Status   New => Closed   
2024-05-20 15:55 Don Cragun Resolution   Open => Rejected
==

Re: Query regarding bug 1825 over certain underspecified memory semantic.

[Geoff Clare via austin-group-l at The Open Group]

Niu Danny wrote, on 20 May 2024:
> 
> I see the bug's still not closed. Would standard maintainers disclose 
> if there's still discussion over this issue?

By coincidence we reached that bug in today's teleconference, and
have processed it as withdrawn based on your comments in the bug.

> Another issue I thought of, but refrained from bringing onto the issue 
> tracker,
> is that in older (not necessarily Unix/POSIX) systems, when there's no
> condition variable, threads would wait for predicates to become true by
> yielding, or sleeping if expiration is needed. Should yield/sleep synchronize
> memory? What's the group's opinion on this?

My personal take is that I only see yield as affecting scheduling.
I.e. it's purely a way for the thread to ask the scheduler to stop
running it earlier than it otherwise would.  So I would not expect
its effect on memory to be any different than if the scheduler
happened to stop running the thread at that point in the code.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

[Issue 8 drafts 0001825]: Does releasing a reader lock carries a "release" memory order semantic?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been CLOSED. 
== 
https://austingroupbugs.net/view.php?id=1825 
== 
Reported By:dannyniu
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1825
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: Closed
Name:   DannyNiu/NJF 
Organization:
User Reference:  
Section:pthread_rwlock_* 
Page Number:1787-1804 
Line Number:59262-59785 
Final Accepted Text: 
Resolution: Withdrawn
Fixed in Version:   
== 
Date Submitted: 2024-04-02 06:44 UTC
Last Modified:  2024-05-20 15:26 UTC
== 
Summary:Does releasing a reader lock carries a "release"
memory order semantic?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-04-02 06:44 dannyniu   New Issue
2024-04-02 06:44 dannyniu   Name  => DannyNiu/NJF
2024-04-02 06:44 dannyniu   Organization  => 
2024-04-02 06:44 dannyniu   Section   => pthread_rwlock_*
2024-04-02 06:44 dannyniu   Page Number   => 1787-1804   
2024-04-02 06:44 dannyniu   Line Number   => 59262-59785 
2024-04-02 15:28 geoffclare Note Added: 0006733  
2024-04-03 04:11 dannyniu   Note Added: 0006735  
2024-04-04 09:09 geoffclare Note Added: 0006736  
2024-04-04 14:34 dannyniu   Note Added: 0006738  
2024-05-20 15:26 nick   Status   New => Closed   
2024-05-20 15:26 nick   Resolution   Open => Withdrawn   
==

[1003.1(2016/18)/Issue7+TC2 0001822]: Define splitting using a null field separator

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1822 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1822
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: Resolved
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1822#c6789 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2024-03-14 11:50 UTC
Last Modified:  2024-05-20 15:09 UTC
== 
Summary:Define splitting using a null field separator
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 11:50 mortoneccc New Issue
2024-03-14 11:50 mortoneccc Name  => Ed Morton   
2024-03-14 11:50 mortoneccc Section   => awk 
2024-03-14 11:50 mortoneccc Page Number   => 0   
2024-03-14 11:50 mortoneccc Line Number   => 0   
2024-05-20 15:08 geoffclare Note Added: 0006789  
2024-05-20 15:09 geoffclare Interp Status => --- 
2024-05-20 15:09 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1822#c6789
2024-05-20 15:09 geoffclare Status   New => Resolved 
2024-05-20 15:09 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001822]: Define splitting using a null field separator

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1822 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1822
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-03-14 11:50 UTC
Last Modified:  2024-05-20 15:08 UTC
== 
Summary:Define splitting using a null field separator
== 

-- 
 (0006789) geoffclare (manager) - 2024-05-20 15:08
 https://austingroupbugs.net/view.php?id=1822#c6789 
-- 
Page and line numbers are for issue 8 draft 4.1.
On P2617, L85671 section awk (EXTENDED DESCRIPTION) change:
If FS is a null string, the behavior is
unspecified.
to:
If FS is a null string, each character shall become a
separate field. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 11:50 mortoneccc New Issue
2024-03-14 11:50 mortoneccc Name  => Ed Morton   
2024-03-14 11:50 mortoneccc Section   => awk 
2024-03-14 11:50 mortoneccc Page Number   => 0   
2024-03-14 11:50 mortoneccc Line Number   => 0   
2024-05-20 15:08 geoffclare Note Added: 0006789  
==

Query regarding bug 1825 over certain underspecified memory semantic.

[Niu Danny via austin-group-l at The Open Group]

Hi all,

I see the bug's still not closed. Would standard maintainers disclose 
if there's still discussion over this issue?

Another issue I thought of, but refrained from bringing onto the issue tracker,
is that in older (not necessarily Unix/POSIX) systems, when there's no
condition variable, threads would wait for predicates to become true by
yielding, or sleeping if expiration is needed. Should yield/sleep synchronize
memory? What's the group's opinion on this?

(When I say not necessarily Unix/POSIX, I meant WinXP: 
https://stackoverflow.com/q/75479678/6230282)

Thanks.
DannyNiu/NJF.

[Issue 8 drafts 0001824]: cp: directories and symlinks

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1824 
== 
Reported By:dag-erling
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1824
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   Dag-Erling Smørgrav 
Organization:
User Reference:  
Section:Utilities 
Page Number:2741-2748 
Line Number:90593-90715, 90876-90880 
Final Accepted Text: 
== 
Date Submitted: 2024-04-01 15:31 UTC
Last Modified:  2024-05-20 09:26 UTC
== 
Summary:cp: directories and symlinks
== 

-- 
 (0006788) geoffclare (manager) - 2024-05-20 09:26
 https://austingroupbugs.net/view.php?id=1824#c6788 
-- 
Before we can work on wording, we need to decide what behaviour(s) to
require/allow for -P.  We should be guided by existing practice.

I tried a few tests on the systems I have access to.

- First I tried this:mkdir targdir; ln -s targdir destdir echo src >
src cp -RP src destdirand cp created src in targdir (on Solaris,
Linux, and macOS).

- Then I tried this:mkdir destdir; cd destdir; echo targ > targ; ln -s
targ src cd ..; echo src > src cp -RP src destdirand cp copied src
contents into the targ file (on Solaris, Linux, and macOS).

- Then I tried this:mkdir subdir destdir; cd destdir; mkdir targdir;
ln -s targdir subdir cd ../subdir; echo src > src; cd .. cp -RP subdir
destdirSolaris and macOS created src in targdir.
Linux failed with "cannot overwrite non-directory 'destdir/subdir' with
directory 'subdir'"

Conclusion: Solaris and macOS consistently follow destination symlinks, as
does historical FreeBSD according to the bug description, but Linux (GNU
coreutils 9.1 on a Debian system) is inconsistent; it follows destination
symlinks in two out of three of my test cases but does not in the other
case. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-04-01 15:31 dag-erling New Issue
2024-04-01 15:31 dag-erling Name  => Dag-Erling
Smørgrav
2024-04-01 15:31 dag-erling Section   => Utilities   
2024-04-01 15:31 dag-erling Page Number   => 2741-2748   
2024-04-01 15:31 dag-erling Line Number   => 90593-90715,
90876-90880
2024-04-02 06:19 dannyniu   Note Added: 0006731  
2024-04-02 06:20 dannyniu   Note Added: 0006732  
2024-04-02 06:21 dannyniu   Note Deleted: 0006732
2024-04-02 06:22 dannyniu   Note Edited: 0006731 
2024-04-02 15:51 geoffclare Note Added: 0006734  
2024-04-04 14:30 geoffclare Note Added: 0006737  
2024-04-04 16:01 dag-erling Note Added: 0006739  
2024-04-04 16:59 geoffclare Note Added: 0006740  
2024-04-04 18:19 geoffclare Note Edited: 0006740 
2024-04-05 08:16 geoffclare Note Edited: 0006740 
2024-04-05 11:33 dag-erling Note Added: 0006741  
2024-04-08 08:39 geoffclare Note Added: 0006743  
2024-04-08 08:42 geoffclare Note Edited: 0006737 
2024-04-08 08:44 geoffclare Note Edited: 0006743 
2024-05-20 09:26 geoffclare Note Added: 0006788  
==

[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1830 
== 
Reported By:lacos
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1830
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   László Érsek 
Organization:
User Reference:  
Section:pwrite, write 
Page Number:? 
Line Number:? 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-03 06:55 UTC
Last Modified:  2024-05-20 08:16 UTC
== 
Summary:off-by-one error regarding offset maximum
== 

-- 
 (0006786) geoffclare (manager) - 2024-05-20 08:16
 https://austingroupbugs.net/view.php?id=1830#c6786 
-- 
Good catch that my proposed fix doesn't work for pwrite().  Having looked
into it some more, I notice that the wording of the associated EFBIG error
works fine for both:[EFBIG]The file is a regular
file, nbyte is greater than 0, and the starting position is greater
than or equal to the offset maximum established in the open file
description associated with fildes.
So I think the text in the description should be worded in a similar way.
The only difference is that the description needs to allow for writes that
start before the offset maximum but would extend beyond it (if all
requested bytes were written).

Change:For regular files, no data transfer shall occur past the
offset maximum established in the open file description associated with
fildes.to:For regular files, no data shall
be written at positions greater than or equal to the offset maximum
established in the open file description associated with fildes. If
the starting position is greater than or equal to the offset maximum (and
nbyte is greater than 0), the request shall fail; otherwise, only as
many bytes as there is room for shall be written. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-03 06:55 lacos  New Issue
2024-05-03 06:55 lacos  Name  => László Érsek 
2024-05-03 06:55 lacos  Section   => pwrite, write   
2024-05-03 06:55 lacos  Page Number   => ?   
2024-05-03 06:55 lacos  Line Number   => ?   
2024-05-13 09:10 geoffclare Note Added: 0006778  
2024-05-19 10:20 lacos  Note Added: 0006784  
2024-05-19 10:26 lacos  Note Added: 0006785  
2024-05-20 08:16 geoffclare Note Added: 0006786  
==

Re: [elixir-core:11755] [Proposal] Add recall to IEX

[Austin Ziegler]

Iex history is controlled through the Erlang shell configuration:

export ERL_AFLAGS="-kernel shell_history enabled shell_history_file_bytes
5242880"

in your shell initialization will produce the expected results with
readline support.

-a

On Sun, May 19, 2024 at 1:54 PM Razi Shaban  wrote:

> Hi,
>
> Certain terminals allow you to : "up" -> retrieve the last-run command,
> "up again" the one before, etc.
>
> A convenience feature that may not be necessary but is sometimes
> satisfying.
>
> thank you,
> Razi
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/b98ee744-6abe-4463-8ace-545d4b4bda98n%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/b98ee744-6abe-4463-8ace-545d4b4bda98n%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQu8d3kZa2jkgiqThO-Kwep8wKVtGCPTRdqF_00ghS-Leg%40mail.gmail.com.

[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1830 
== 
Reported By:lacos
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1830
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   László Érsek 
Organization:
User Reference:  
Section:pwrite, write 
Page Number:? 
Line Number:? 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-03 06:55 UTC
Last Modified:  2024-05-19 10:26 UTC
== 
Summary:off-by-one error regarding offset maximum
== 

-- 
 (0006785) lacos (reporter) - 2024-05-19 10:26
 https://www.austingroupbugs.net/view.php?id=1830#c6785 
-- 
My reason for covering pwrite() as well is the following: an application
may maintain a separate off_t variable for recording the exclusive end
offset of a successful pwrite() call -- effectively the same offset to
which an equivalent write() call would set the file offset inside the
underlying open file description. Given that the spec intends to prevent
the file offset inside the open file description from overflowing upon a
write(), the same guarantee should be extended to an application that
captures the same "exclusive end of successful data transfer" concept in an
off_t object. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-03 06:55 lacos  New Issue
2024-05-03 06:55 lacos  Name  => László Érsek 
2024-05-03 06:55 lacos  Section   => pwrite, write   
2024-05-03 06:55 lacos  Page Number   => ?   
2024-05-03 06:55 lacos  Line Number   => ?   
2024-05-13 09:10 geoffclare Note Added: 0006778  
2024-05-19 10:20 lacos  Note Added: 0006784  
2024-05-19 10:26 lacos  Note Added: 0006785  
==

[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1830 
== 
Reported By:lacos
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1830
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   László Érsek 
Organization:
User Reference:  
Section:pwrite, write 
Page Number:? 
Line Number:? 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-03 06:55 UTC
Last Modified:  2024-05-19 10:20 UTC
== 
Summary:off-by-one error regarding offset maximum
== 

-- 
 (0006784) lacos (reporter) - 2024-05-19 10:20
 https://www.austingroupbugs.net/view.php?id=1830#c6784 
-- 
The proposed update entirely clarifies the requirement for write(), however
I think it applies less to pwrite() than before, because pwrite() does not
change the file offset at all.

(In retrospect, I suspect the original "data transfer [...] past the offset
maximum" language may have specifically aimed at covering pwrite() at the
same time as write().)

Can we perhaps use semi-formal syntax, such as:

"For regular files, no data transfer shall occur such that, using
zero-based byte offsets, /byte[offmax]/ of the file, or any byte
thereafter, be overwritten, where offmax is the offset maximum established
in the open file description associated with fildes." 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-03 06:55 lacos  New Issue
2024-05-03 06:55 lacos  Name  => László Érsek 
2024-05-03 06:55 lacos  Section   => pwrite, write   
2024-05-03 06:55 lacos  Page Number   => ?   
2024-05-03 06:55 lacos  Line Number   => ?   
2024-05-13 09:10 geoffclare Note Added: 0006778  
2024-05-19 10:20 lacos  Note Added: 0006784  
==

Re: [Opensim-users] Opensim-dev Digest, Vol 95, Issue 1

[Ai Austin]

Does anyone know where to change the MinSimHeight for OpenSim
(defaults to -100m I believe).

I can't find reference to it in OpenSim.ini.example or OpeSimDefaults.ini

On Fri, 16 Feb 2024 at 12:00,  wrote:
>
> Send Opensim-dev mailing list submissions to
> opensim-...@opensimulator.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
> opensim-dev-requ...@opensimulator.org
>
> You can reach the person managing the list at
> opensim-dev-ow...@opensimulator.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
>1. proposal: opensimulator update to DOTNET 7 (Andr? Verwijs)
>
>
> --
>
> Message: 1
> Date: Fri, 16 Feb 2024 07:13:55 +0100
> From: Andr? Verwijs 
> To: opensim-...@opensimulator.org
> Subject: [Opensim-dev] proposal: opensimulator update to DOTNET 7
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> proposal:? opensimulator? update to DOTNET? 7
>
> I have tested on linux and it work great,? (a few warnings but no
> fails)? so if possible update to DOTNET? 7
>
>
> thans
> Andr?
>
>
>
> --
>
> ___
> Opensim-dev mailing list
> opensim-...@opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
> End of Opensim-dev Digest, Vol 95, Issue 1
> **
___
Opensim-users mailing list
Opensim-users@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users

[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1831 
== 
Reported By:philip-guenther
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1831
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Philip Guenther 
Organization:   OpenBSD 
User Reference:  
Section:pathconf 
Page Number:902-907 
Line Number:30519 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-15 08:10 UTC
Last Modified:  2024-05-18 05:57 UTC
== 
Summary:how do you get the timestamp resolution of a
symlink?
== 

-- 
 (0006783) philip-guenther (reporter) - 2024-05-18 05:57
 https://austingroupbugs.net/view.php?id=1831#c6783 
-- 
OpenBSD 7.6 will have
 long
 pathconfat(int fd, const char *path, int name, int flag);

where the flag argument supports AT_SYMLINK_NOFOLLOW. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-15 08:10 philip-guentherNew Issue
2024-05-15 08:10 philip-guentherName  => Philip Guenther 
2024-05-15 08:10 philip-guentherOrganization  => OpenBSD 
2024-05-15 08:10 philip-guentherSection   => pathconf
2024-05-15 08:10 philip-guentherPage Number   => 902-907 
2024-05-15 08:10 philip-guentherLine Number   => 30519   
2024-05-15 17:11 philip-guentherNote Added: 0006780  
2024-05-18 05:57 philip-guentherNote Added: 0006783  
==

Minutes of the 16th May 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of the thursday meeting this week
regards
Andrew
-

Minutes of the 16th May 2024 TeleconferenceAustin-1406 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 18th May 2024


Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Eric Ackermann, CISPA 
Eric Blake, Red Hat, The Open Group OR (joining late)
   
Apologies
Tom Thompson, IEEE
Mark Ziegast, SHware Systems Dev

* General news

There will be no meeting on Monday May 27.


P1003.1 was recommended for approval at the May 6th RevCom meeting.
The Standards Association Standards Board (SASB) electronic ballot
(e-ballot) vote should close early to mid-week next week. Once
closed the RevCom Administrator will typically send an email informing
of the final vote.  After approval we can moved forward to complete
the frontmatter and proceed to publication, and the html conversion.

The ISO/IEC ballot closes on June 28.

* Current Business

1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797

We will continue this item next time that Paul is available (expected in April).


Bug 1818: Add strcasestr() & strcasestr_l() OPEN
https://austingroupbugs.net/view.php?id=1818
Action: Eric B to ask The Open Group if they are willing to sponsor
these functions for Issue 9.

Bug 1821: Define the values of $0, $1, etc. in the END section Accepted as 
Marked
https://austingroupbugs.net/view.php?id=1821

An interpretation required, This is tagged for TC1-2024.

Interpretation response:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based
on this. This is being referred to the sponsor.

Rationale:
The standard requires that the value of NF is retained in an END
section, but does not state what the values of the fields $1 through
$NF are, despite requiring them to exist.

Notes to the Editor (not part of this interpretation):
Page and line numbers are for Issue 8 draft 4.1.

At page 2614 line 85574 (FILENAME), delete:

Inside an END action the value shall be the name of the last
input file processed.

At page 2614 line 85578 (FNR), change:
Inside an END action the value shall be the number of the last
record processed in the last file processed.
to:
If an application changes the value of FNR, the results are
unspecified.

At page 2614 line 85581 (NF), change:
The number of fields in the current record. Inside a BEGIN
action, the use of NF is undefined unless a getline function
without a var argument is executed previously. Inside an END
action, NF shall retain the value it had for the last record
read, unless a subsequent, redirected, getline function without
a var argument is performed prior to entering the END action.
to:
The number of fields in the current record. Inside the first
BEGIN action, the value shall initially be zero, except that
if the -v option was used to assign a value to NF it is unspecified
whether that value is retained or the value is reset to zero.

At page 2614 line 85587 (NR), change:
Inside an END action the value shall be the number of the last
record processed.
to:
If an application changes the value of NR, the results are
unspecified.

At page 2618 after line 85708 (Special Patterns), add:
Entering an END action shall not alter the value of any fields
or variables that had previously been set.

Bug 1822: Define splitting using a null field separator OPEN
https://austingroupbugs.net/view.php?id=1822

We started on this item. Notes are in the etherpad.  We will continue
on this item next time.


Next Steps 
--

The next call is on:
  Mon 2024-05-20 (WEBEX meeting - general bugs)
  Mon 2024-05-27 No meeting
  Thu 2024-05-23 (WEBEX meeting - general bugs)

Apologies in Advance:
Eric Blake 2024-05-20, 2024-05-23
  
The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)




Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Re: endian.h requires uint64_t but stdint.h does not.

[Collin Funk via austin-group-l at The Open Group]

On 5/17/24 9:48 PM, Philip Guenther wrote:
> Yeah, this was noticed back in January and a ticket filed then:
> https://austingroupbugs.net/view.php?id=1799

Oops, I didn't see that. Thanks for the link!

Collin

Re: endian.h requires uint64_t but stdint.h does not.

[Philip Guenther via austin-group-l at The Open Group]

On Fri, May 17, 2024 at 9:33 PM Collin Funk via austin-group-l at The
Open Group  wrote:
> I am not sure how to make an account on the bug tracker. If it is
> preferred that this is submitted there I am happy to do so. I just
> need help with registration.
>
> I am using the 202x Draft 4.1 (February 2024) PDF for references.
>
> In the description of the endian.h header on Page 240, lines 8459 - 8461:
>
>
> The  header shall define the uint16_t, uint32_t, and uint64_t types 
> as described in
> .
> Inclusion of the  header may also make visible all symbols from 
> .
>
>
> It also appears that be64toh, htobe64, htole64, le64toh are required
> to be defined as functions and macros.

Yeah, this was noticed back in January and a ticket filed then:
https://austingroupbugs.net/view.php?id=1799

To quote from the resolution there:
--

Interpretation response

The standard states that uint64_t is required to be defined by
 but is optional in , and conforming
implementations must conform to this. However, concerns have been
raised about this which are being referred to the sponsor.

Rationale:
-
Since implementations need to support uint64_t in order to implement
, there is no point in having it be optionally defined in
. For symmetry, int64_t should also be required in
.



Philip Guenther

endian.h requires uint64_t but stdint.h does not.

[Collin Funk via austin-group-l at The Open Group]

Hello,

I am not sure how to make an account on the bug tracker. If it is
preferred that this is submitted there I am happy to do so. I just
need help with registration.

I am using the 202x Draft 4.1 (February 2024) PDF for references.

In the description of the endian.h header on Page 240, lines 8459 - 8461:


The  header shall define the uint16_t, uint32_t, and uint64_t types 
as described in
.
Inclusion of the  header may also make visible all symbols from 
.


It also appears that be64toh, htobe64, htole64, le64toh are required
to be defined as functions and macros.

I believe that this is an issue because uint64_t is not a required
type. In the documentation for stdint.h on page 370, lines 12947 -
12957:


The following types are required:

int8_t
int16_t
int32_t
uint8_t
uint16_t
uint32_t

If an implementation provides integer types with width 64 that meet these 
requirements,
then the following types are required:

int64_t
uint64_t


Perhaps the 64 bit byte order conversions should be made optional and
uint64_t is made available in endian.h if it is supported?

Thanks,
Collin

Adopt Email::MIME::Attachment::Stripper?

[Wendy Austin via modules]

Hello,

mime-attachment 2
Description: Binary data


I'm interested in adopting the Email::MIME::Attachment::Stripper module. If you 
can grant me the privilege I will release the next version.


Sent from my iPhone

Re: [AI] talking health products

[Austin Pinto]

found only 1 health product which is puls oximeter what about bp
machine and tharmomeater

On Fri, May 17, 2024 at 6:24 PM Radio Udaan  wrote:

>
>> Visit enablemart.in
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of
> the person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAEDCw1ZJ_nS%2BwSwy%3DBziNAL7gQx8YQB-FRVg%2BeO%2B30m6c2yY_A%40mail.gmail.com
> 
> .
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or whatever
with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi-wLtnBip6rOosQpf0Y3P%3D05rkg63aOcij3-bBQr7uMJg%40mail.gmail.com.

[AI] talking health products

[Austin Pinto]

hi all.
can you give me all the links to accessible health products like
talking Thermometers
bp machines and so on.
preferable from amazon but if from another place also will do

-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or whatever
with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi9rkyJgctnN8wJpqM3_rgTG7eqa8YrC9CTpqZDBcji_Aw%40mail.gmail.com.

[1003.1(2016/18)/Issue7+TC2 0001823]: The impact of changing NR and/or FNR should be defined

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1823 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1823
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: Resolved
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1823#c6782 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2024-03-14 12:26 UTC
Last Modified:  2024-05-16 15:55 UTC
== 
Summary:The impact of changing NR and/or FNR should be
defined
==
Relationships   ID  Summary
--
related to  0001821 Define the values of $0, $1, etc. in th...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 12:26 mortoneccc New Issue
2024-03-14 12:26 mortoneccc Name  => Ed Morton   
2024-03-14 12:26 mortoneccc Section   => awk 
2024-03-14 12:26 mortoneccc Page Number   => 0   
2024-03-14 12:26 mortoneccc Line Number   => 0   
2024-03-14 12:27 mortoneccc Note Added: 0006720  
2024-05-16 15:54 eblake Relationship added   related to 0001821  
2024-05-16 15:54 geoffclare Note Added: 0006782  
2024-05-16 15:55 geoffclare Interp Status => --- 
2024-05-16 15:55 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1823#c6782
2024-05-16 15:55 geoffclare Status   New => Resolved 
2024-05-16 15:55 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001823]: The impact of changing NR and/or FNR should be defined

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1823 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1823
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-03-14 12:26 UTC
Last Modified:  2024-05-16 15:54 UTC
== 
Summary:The impact of changing NR and/or FNR should be
defined
==
Relationships   ID  Summary
--
related to  0001821 Define the values of $0, $1, etc. in th...
== 

-- 
 (0006782) geoffclare (manager) - 2024-05-16 15:54
 https://austingroupbugs.net/view.php?id=1823#c6782 
-- 
After applying bug https://austingroupbugs.net/view.php?id=1821, make the
following change:

Page and line numbers are for Issue 8 draft 4.1.

After page 2642 line 86769 section awk (FUTURE DIRECTIONS), add a new
paragraph:
A future version of this standard may specify the behavior when
an application assigns a value to NR or FNR. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 12:26 mortoneccc New Issue
2024-03-14 12:26 mortoneccc Name  => Ed Morton   
2024-03-14 12:26 mortoneccc Section   => awk 
2024-03-14 12:26 mortoneccc Page Number   => 0   
2024-03-14 12:26 mortoneccc Line Number   => 0   
2024-03-14 12:27 mortoneccc Note Added: 0006720  
2024-05-16 15:54 eblake Relationship added   related to 0001821  
2024-05-16 15:54 geoffclare Note Added: 0006782  
==

[1003.1(2016/18)/Issue7+TC2 0001821]: Define the values of $0, $1, etc. in the END section

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 0001823. 
== 
https://austingroupbugs.net/view.php?id=1821 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1821
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: Interpretation Required
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  Pending 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1821#c6781 
== 
Date Submitted: 2024-03-14 11:42 UTC
Last Modified:  2024-05-16 15:33 UTC
== 
Summary:Define the values of $0, $1, etc. in the END section
==
Relationships   ID  Summary
--
related to  0001823 The impact of changing NR and/or FNR sh...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 11:42 mortoneccc New Issue
2024-03-14 11:42 mortoneccc Name  => Ed Morton   
2024-03-14 11:42 mortoneccc Section   => awk 
2024-03-14 11:42 mortoneccc Page Number   => 0   
2024-03-14 11:42 mortoneccc Line Number   => 0   
2024-03-14 12:03 geoffclare Note Added: 0006719  
2024-05-16 15:31 geoffclare Note Added: 0006781  
2024-05-16 15:33 geoffclare Interp Status => Pending 
2024-05-16 15:33 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1821#c6781
2024-05-16 15:33 geoffclare Status   New => Interpretation
Required
2024-05-16 15:33 geoffclare Resolution   Open => Accepted As
Marked
2024-05-16 15:33 geoffclare Tag Attached: tc1-2024   
2024-05-16 15:54 eblake Relationship added   related to 0001823  
==

[1003.1(2016/18)/Issue7+TC2 0001823]: The impact of changing NR and/or FNR should be defined

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 0001821. 
== 
https://austingroupbugs.net/view.php?id=1823 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1823
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-03-14 12:26 UTC
Last Modified:  2024-05-16 15:54 UTC
== 
Summary:The impact of changing NR and/or FNR should be
defined
==
Relationships   ID  Summary
--
related to  0001821 Define the values of $0, $1, etc. in th...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 12:26 mortoneccc New Issue
2024-03-14 12:26 mortoneccc Name  => Ed Morton   
2024-03-14 12:26 mortoneccc Section   => awk 
2024-03-14 12:26 mortoneccc Page Number   => 0   
2024-03-14 12:26 mortoneccc Line Number   => 0   
2024-03-14 12:27 mortoneccc Note Added: 0006720  
2024-05-16 15:54 eblake Relationship added   related to 0001821  
==

[1003.1(2016/18)/Issue7+TC2 0001821]: Define the values of $0, $1, etc. in the END section

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue NEEDS AN INTERPRETATION. 
== 
https://austingroupbugs.net/view.php?id=1821 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1821
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: Interpretation Required
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  Pending 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1821#c6781 
== 
Date Submitted: 2024-03-14 11:42 UTC
Last Modified:  2024-05-16 15:33 UTC
== 
Summary:Define the values of $0, $1, etc. in the END section
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 11:42 mortoneccc New Issue
2024-03-14 11:42 mortoneccc Name  => Ed Morton   
2024-03-14 11:42 mortoneccc Section   => awk 
2024-03-14 11:42 mortoneccc Page Number   => 0   
2024-03-14 11:42 mortoneccc Line Number   => 0   
2024-03-14 12:03 geoffclare Note Added: 0006719  
2024-05-16 15:31 geoffclare Note Added: 0006781  
2024-05-16 15:33 geoffclare Interp Status => Pending 
2024-05-16 15:33 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1821#c6781
2024-05-16 15:33 geoffclare Status   New => Interpretation
Required
2024-05-16 15:33 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001821]: Define the values of $0, $1, etc. in the END section

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1821 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1821
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-03-14 11:42 UTC
Last Modified:  2024-05-16 15:31 UTC
== 
Summary:Define the values of $0, $1, etc. in the END section
== 

-- 
 (0006781) geoffclare (manager) - 2024-05-16 15:31
 https://austingroupbugs.net/view.php?id=1821#c6781 
-- 
Interpretation response


The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.

Rationale:
-
The standard requires that the value of NF is retained in an END section,
but does not state what the values of the fields $1 through $NF are,
despite requiring them to exist.

Notes to the Editor (not part of this interpretation):
---
Page and line numbers are for Issue 8 draft 4.1.

At page 2614 line 85574 (FILENAME), delete:
Inside an END action the value shall be the name of the
last input file processed.

At page 2614 line 85578 (FNR), change:
Inside an END action the value shall be the number of
the last record processed in the last file processed.
to:
If an application changes the value of FNR, the results
are unspecified.

At page 2614 line 85581 (NF), change:
The number of fields in the current record. Inside a
BEGIN action, the use of NF is undefined unless a getline
function without a var argument is executed previously.  Inside an
END action, NF shall retain the value it had for the last
record read, unless a subsequent, redirected, getline function without a
var argument is performed prior to entering the END
action.
to:
The number of fields in the current record. Inside the first
BEGIN action, the value shall initially be zero, except that if the
-v option was used to assign a value to NF it is unspecified
whether that value is retained or the value is reset to zero.

At page 2614 line 85587 (NR), change:
Inside an END action the value shall be the number of
the last record processed.
to:
If an application changes the value of NR, the results
are unspecified.

At page 2618 after line 85708 (Special Patterns), add:
Entering an END action shall not alter the value of any
fields or variables that had previously been set. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 11:42 mortoneccc New Issue
2024-03-14 11:42 mortoneccc Name  => Ed Morton   
2024-03-14 11:42 mortoneccc Section   => awk 
2024-03-14 11:42 mortoneccc Page Number   => 0   
2024-03-14 11:42 mortoneccc Line Number   => 0   
2024-03-14 12:03 geoffclare Note Added: 0006719  
2024-05-16 15:31 geoffclare Note Added: 0006781  
==

Austin Group WEBEX +1-408-792-6300 PIN 668 216 233

[Single UNIX Specification via austin-group-l at The Open Group]

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:6646219d09...@opengroup.org
DTSTAMP:20240516T150917Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240516T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group WEB
 EX +1-408-792-6300 PIN 668 216 233\nDate/Time: 23-May-2024 at 11:00 Americ
 a/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengroup.org
 /platform/single_unix_specification/events.php\n\nAll calls are anchored o
 n US time\n\nTopic: Austin Group teleconference\n-
 --\nAudio conference information\n
 ---\n\nYou are invited to a WEBEX 
 meeting. \n
DTSTART;TZID=America/New_York:20240523T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240516T110917Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group WEBEX +1-408-792-6300 PIN 668 216 233
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

Minutes of the 13th May 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of the Monday meeting this week
regards
Andrew
-

Minutes of the 13th May 2024 TeleconferenceAustin-1405 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 15th May 2024


Attendees:
Andrew Josey, The Open Group
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE SA OR
Geoff Clare, The Open Group
Eric Blake, Red Hat, The Open Group OR
Eric Ackermann, CISPA
Brooks Harris
   
Apologies
Tom Thompson, IEEE
Mark Ziegast, SHware Systems Dev

* General news

There will be no meeting on Monday May 27.

The general news is unchanged.

The IEEE Revcom committee met on May 6 to consider approval of draft 4.1.
We have yet to hear the result.
After approval we can moved forward to complete the frontmatter
and proceed to publication, and the html conversion.

The ISO/IEC ballot closes on June 28.

* Current Business

1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797

We will continue this item next time that Paul is available (expected in April).


Bug 1818: Add strcasestr() & strcasestr_l() OPEN
https://austingroupbugs.net/view.php?id=1818
Action: Eric B to ask The Open Group if they are willing to sponsor
these functions for Issue 9.

Bug 1820: The impact of changing NF should be stated Accepted as Marked
https://austingroupbugs.net/view.php?id=1820

This item is tagged for Issue 9.

On Issue 8 draft 4.1 page 2613 line 85507, change:
Field variables shall be designated by a '$' followed by a
number or numerical expression. The effect of the field number
expression evaluating to anything other than a non-negative
integer is unspecified; uninitialized variables or string values
need not be converted to numeric values in this context. New
field variables can be created by assigning a value to them.
References to nonexistent fields (that is, fields after $NF),
shall evaluate to the uninitialized value. Such references shall
not create new fields. However, assigning to a nonexistent field
(for example, $(NF+2)=5) shall increase the value of NF; create
any intervening fields with the uninitialized value; and cause
the value of $0 to be recomputed, with the fields being separated
by the value of OFS. Each field variable shall have a string
value or an uninitialized value when created. Field variables
shall have the uninitialized value when created from $0 using
FS and the variable does not contain any characters. If
appropriate, the field variable shall be considered a numeric
string (see Expressions in awk, on page 2608).
to:
Field variables shall be designated by a '$' followed by a
number or numerical expression. The effect of the field number
expression evaluating to anything other than a non-negative
integer is unspecified; uninitialized variables or string values
need not be converted to numeric values in this context. Each
field variable shall have a string value or an uninitialized
value when created. Field variables shall have the uninitialized
value when created from $0 using FS and the variable does not
contain any characters. If appropriate, the field variable shall
be considered a numeric string (see Expressions in awk, on page
2608).

New field variables can be created by assigning a value to them.
References to nonexistent fields (that is, fields after $NF),
shall evaluate to the uninitialized value. Such references shall
not create new fields. However, assigning to a nonexistent field
(for example, $(NF+2)=5) shall increase the value of NF; create
any intervening fields with the uninitialized value; and cause
the value of $0 to be recomputed, with the fields being separated
by the value of OFS. Directly increasing the value of NF (for
example, NF += 2) shall have the same effect as assigning an
empty string to $NF (where NF has its new value). Decreasing
the value of NF to a non-negative value shall remove all fields
after $NF and cause the value of $0 to be recomputed, with the
fields being separated by the value of OFS. Assigning to NF
without changing its value (for example, NF = NF) shall cause
the value of $0 to be recomputed, with the fields being separated
by the value of OFS.

Bug 1821: Define the values of $0, $1, etc. in the END section OPEN
https://austingroupbugs.net/view.php?id=1821

We started on this item. Notes are in the etherpad.
We will continue on this item next time.


Next Steps 
--

The next call is on:
  Thu 2024-05-16 (WEBEX meeting - general bugs)
  Mon 2024-05-20 (WEBEX meeting - general bugs)

Note:  Mon 2024-05-27 No meeting
  

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad

Austin Group WEBEX +1-408-792-6300 PIN 668 216 233

[Single UNIX Specification via austin-group-l at The Open Group]

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:664500c6ea...@opengroup.org
DTSTAMP:20240515T183655Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240515T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group WEB
 EX +1-408-792-6300 PIN 668 216 233\nDate/Time: 20-May-2024 at 11:00 Americ
 a/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengroup.org
 /platform/single_unix_specification/events.php\n\nAll calls are anchored o
 n US time\n\nTopic: Austin Group teleconference\n-
 --\nAudio conference information\n
 ---\n\nYou are invited to a WEBEX 
 meeting. \n
DTSTART;TZID=America/New_York:20240520T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240515T143655Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group WEBEX +1-408-792-6300 PIN 668 216 233
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

[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1831 
== 
Reported By:philip-guenther
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1831
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Philip Guenther 
Organization:   OpenBSD 
User Reference:  
Section:pathconf 
Page Number:902-907 
Line Number:30519 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-15 08:10 UTC
Last Modified:  2024-05-15 08:10 UTC
== 
Summary:how do you get the timestamp resolution of a
symlink?
Description: 
The description of pathconf() doesn't contain any specific wording about
how it should handle a path which names a symlink.  Contrast rename()'s
description which says
If either the old or new argument names a symbolic link, rename()
shall
operate on the symbolic link itself, and shall not resolve the last
component of the argument.

and unlink()'s description which says
If path names a symbolic link, unlink() shall remove the symbolic link
named by path and shall not affect any file or directory named by the
contents of the symbolic link.

It thus appears that pathconf() is expected to completely follow symlinks
and report the values appropriate for the final result of the pathname
resolution.

However, it would be useful to be able to get the timestamp resolution
(_PC_TIMESTAMP_RESOLUTION) for a symlink, even if it's dangling or points
to a path on a filesystem with a different timestamp resolution.


(This was encountered when trying to fix a pax implementation's handling of
timestamp comparison for -u when the target filesystem had courser
resolution that the source filesystem by using
pathconf(_PC_TIMESTAMP_RESOLUTION) on the target path to handle the loss of
high-precision time info...but the symlink pointed to a location with
high-precision timestamps so it couldn't know to round the times when doing
the comparison...)

Desired Action: 
Got me!  Change pathconf() to never follow a final symlink, ala rename(),
unlink(), open(O_NOFOLLOW)?  Never follow a terminal symlink when the
second argument is _PC_TIMESTAMP_RESOLUTION?  A new
_PC_TIMESTAMP_RESOLUTION_NOFOLLOW???

(cries)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-15 08:10 philip-guentherNew Issue
2024-05-15 08:10 philip-guentherName  => Philip Guenther 
2024-05-15 08:10 philip-guentherOrganization  => OpenBSD 
2024-05-15 08:10 philip-guentherSection   => pathconf
2024-05-15 08:10 philip-guentherPage Number   => 902-907 
2024-05-15 08:10 philip-guentherLine Number   => 30519   
==

[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1831 
== 
Reported By:philip-guenther
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1831
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Philip Guenther 
Organization:   OpenBSD 
User Reference:  
Section:pathconf 
Page Number:902-907 
Line Number:30519 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-15 08:10 UTC
Last Modified:  2024-05-15 17:11 UTC
== 
Summary:how do you get the timestamp resolution of a
symlink?
== 

-- 
 (0006780) philip-guenther (reporter) - 2024-05-15 17:11
 https://austingroupbugs.net/view.php?id=1831#c6780 
-- 
With a fresh cup of coffee, it's 'obvious' the correct action is to use
  pathconfat(AT_FDCWD, path, _PC_TIMESTAMP_RESOLUTION,
AT_SYMLINK_NOFOLLOW)

This was touched on in https://austingroupbugs.net/view.php?id=786 (c.f.
Geoff's comment 2827 from 2015) so maybe I should just implement this in
OpenBSD and drag everyone else along from there.  :) 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-15 08:10 philip-guentherNew Issue
2024-05-15 08:10 philip-guentherName  => Philip Guenther 
2024-05-15 08:10 philip-guentherOrganization  => OpenBSD 
2024-05-15 08:10 philip-guentherSection   => pathconf
2024-05-15 08:10 philip-guentherPage Number   => 902-907 
2024-05-15 08:10 philip-guentherLine Number   => 30519   
2024-05-15 17:11 philip-guentherNote Added: 0006780  
==

[1003.1(2016/18)/Issue7+TC2 0001831]: how do you get the timestamp resolution of a symlink?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1831 
== 
Reported By:philip-guenther
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1831
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Philip Guenther 
Organization:   OpenBSD 
User Reference:  
Section:pathconf 
Page Number:902-907 
Line Number:30519 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-15 08:10 UTC
Last Modified:  2024-05-15 08:10 UTC
== 
Summary:how do you get the timestamp resolution of a
symlink?
Description: 
The description of pathconf() doesn't contain any specific wording about
how it should handle a path which names a symlink.  Contrast rename()'s
description which says
If either the old or new argument names a symbolic link, rename()
shall
operate on the symbolic link itself, and shall not resolve the last
component of the argument.

and unlink()'s description which says
If path names a symbolic link, unlink() shall remove the symbolic link
named by path and shall not affect any file or directory named by the
contents of the symbolic link.

It thus appears that pathconf() is expected to completely follow symlinks
and report the values appropriate for the final result of the pathname
resolution.

However, it would be useful to be able to get the timestamp resolution
(_PC_TIMESTAMP_RESOLUTION) for a symlink, even if it's dangling or points
to a path on a filesystem with a different timestamp resolution.


(This was encountered when trying to fix a pax implementation's handling of
timestamp comparison for -u when the target filesystem had courser
resolution that the source filesystem by using
pathconf(_PC_TIMESTAMP_RESOLUTION) on the target path to handle the loss of
high-precision time info...but the symlink pointed to a location with
high-precision timestamps so it couldn't know to round the times when doing
the comparison...)

Desired Action: 
Got me!  Change pathconf() to never follow a final symlink, ala rename(),
unlink(), open(O_NOFOLLOW)?  Never follow a terminal symlink when the
second argument is _PC_TIMESTAMP_RESOLUTION?  A new
_PC_TIMESTAMP_RESOLUTION_NOFOLLOW???

(cries)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-15 08:10 philip-guentherNew Issue
2024-05-15 08:10 philip-guentherName  => Philip Guenther 
2024-05-15 08:10 philip-guentherOrganization  => OpenBSD 
2024-05-15 08:10 philip-guentherSection   => pathconf
2024-05-15 08:10 philip-guentherPage Number   => 902-907 
2024-05-15 08:10 philip-guentherLine Number   => 30519   
==

Re: Request RFC3339 format option for date utility

[Robert Elz via austin-group-l at The Open Group]

Date:Sun, 12 May 2024 18:59:51 -0500
From:"Andrew Pennebaker via austin-group-l at The Open Group" 

Message-ID:  


I do not send mail to @gmail addresses, so I will reply just to the list.

  | I would like the standard POSIX date utility to receive an option to format
  | timestamps with modern RFC3339 format.

This is not the appropriate forum to make that happen - you'd need
to get the various implementations to agree on a new option, which
once common, could then be proposed to be added to the standard.

I don't really see the need for that 3339 format is trivial to
produce already...

jacaranda$ date -u +%Y-%m-%dT%H:%M:%SZ
2024-05-13T07:20:06Z

(That isn't GNU date, but I'd be a little surprised if it couldn't
do the same).

  | The GNU date utility seems to do this poorly, using the overly elaborate
  | pattern "...+00:00" instead of "...Z" for UTC timezone.

That's allowed by 3339, if you don't like it, or want an option to
change just that, you should take that up with the maintainers of
GNU date, not here.

kre

[1003.1(2016/18)/Issue7+TC2 0001820]: The impact of changing NF should be stated

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1820 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1820
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: Resolved
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1820#c6779 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2024-03-14 11:36 UTC
Last Modified:  2024-05-13 15:08 UTC
== 
Summary:The impact of changing NF should be stated
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 11:36 mortoneccc New Issue
2024-03-14 11:36 mortoneccc Name  => Ed Morton   
2024-03-14 11:36 mortoneccc Section   => awk 
2024-03-14 11:36 mortoneccc Page Number   => 0   
2024-03-14 11:36 mortoneccc Line Number   => 0   
2024-03-15 13:50 salewski   Issue Monitored: salewski
2024-05-13 15:07 geoffclare Note Added: 0006779  
2024-05-13 15:08 geoffclare Interp Status => --- 
2024-05-13 15:08 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1820#c6779
2024-05-13 15:08 geoffclare Status   New => Resolved 
2024-05-13 15:08 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001820]: The impact of changing NF should be stated

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1820 
== 
Reported By:mortoneccc
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1820
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Comment
Priority:   normal
Status: New
Name:   Ed Morton 
Organization:
User Reference:  
Section:awk 
Page Number:0 
Line Number:0 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-03-14 11:36 UTC
Last Modified:  2024-05-13 15:07 UTC
== 
Summary:The impact of changing NF should be stated
== 

-- 
 (0006779) geoffclare (manager) - 2024-05-13 15:07
 https://austingroupbugs.net/view.php?id=1820#c6779 
-- 
On Issue 8 draft 4.1 page 2613 line 85507, change:
Field variables shall be designated by a '$' followed by a
number or numerical expression. The effect of the field number
expression evaluating to anything other than a non-negative integer
is unspecified; uninitialized variables or string values need not be
converted to numeric values in this context. New field variables can be
created by assigning a value to them. References to nonexistent fields
(that is, fields after $NF), shall evaluate to the uninitialized
value. Such references shall not create new fields. However, assigning to a
nonexistent field (for example, $(NF+2)=5) shall increase the value
of NF; create any intervening fields with the uninitialized value;
and cause the value of $0 to be recomputed, with the fields being separated
by the value of OFS. Each field variable shall have a string value
or an uninitialized value when created. Field variables shall have the
uninitialized value when created from $0 using FS and the variable
does not contain any characters. If appropriate, the field variable shall
be considered a numeric string (see Expressions in awk, on page
2608).
to:
Field variables shall be designated by a '$' followed by a
number or numerical expression. The effect of the field number
expression evaluating to anything other than a non-negative integer
is unspecified; uninitialized variables or string values need not be
converted to numeric values in this context. Each field variable shall have
a string value or an uninitialized value when created. Field variables
shall have the uninitialized value when created from $0 using FS and
the variable does not contain any characters. If appropriate, the field
variable shall be considered a numeric string (see Expressions in awk, on
page 2608).

New field variables can be created by assigning a value to them. References
to nonexistent fields (that is, fields after $NF), shall evaluate to
the uninitialized value. Such references shall not create new fields.
However, assigning to a nonexistent field (for example, $(NF+2)=5)
shall increase the value of NF; create any intervening fields with
the uninitialized value; and cause the value of $0 to be recomputed, with
the fields being separated by the value of OFS. Directly increasing
the value of NF (for example, NF += 2) shall have the same
effect as assigning an empty string to $NF (where NF has its
new value). Decreasing the value of NF to a non-negative value shall
remove all fields after $NF and cause the value of $0 to be
recomputed, with the fields being separated by the value of OFS.
Assigning to NF without changing its value (for example, NF =
NF) shall cause the value of $0 to be recomputed, with the fields
being separated by the value of OFS. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-03-14 11:36 mortoneccc New Issue
2024-03-14 11:36 mortoneccc Name  => Ed Morton   
2024-03-14 11:36 mortoneccc Section   => awk 
2024-03-14 11:36 mortoneccc Page Number   => 0   
2024-03-14 11:36 mortoneccc Line Number   => 0   
2024-03-15 13:50 salewski   Issue Monitored: salewski
2024-05-13 15:07 geoffclare Note Added: 0006779 

[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1830 
== 
Reported By:lacos
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1830
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   László Érsek 
Organization:
User Reference:  
Section:pwrite, write 
Page Number:? 
Line Number:? 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-03 06:55 UTC
Last Modified:  2024-05-13 09:10 UTC
== 
Summary:off-by-one error regarding offset maximum
== 

-- 
 (0006778) geoffclare (manager) - 2024-05-13 09:10
 https://austingroupbugs.net/view.php?id=1830#c6778 
-- 
This seems to be a difference in understanding of what the standard means
when it refers to data transfer past a given offset.

My understanding matches the way I believe that the author(s) of that text
intended it to be read. Taking the example of offset 127, to me this code:

lseek(fd, 127, SEEK_SET);
write(fd, "X", 1);

results in data transfer past the offset 127, because the new offset is 128
which is greater than 127.

It appears that other people understand the phrase differently.

This should be solved by changing the phrasing to something that can't be
understood in different ways. For example:For regular files, no
data transfer shall occur that would result in the file offset being set to
a value greater than the offset maximum established in the open file
description associated with fildes. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-03 06:55 lacos  New Issue
2024-05-03 06:55 lacos  Name  => László Érsek 
2024-05-03 06:55 lacos  Section   => pwrite, write   
2024-05-03 06:55 lacos  Page Number   => ?   
2024-05-03 06:55 lacos  Line Number   => ?   
2024-05-13 09:10 geoffclare Note Added: 0006778  
==

Request RFC3339 format option for date utility

[Andrew Pennebaker via austin-group-l at The Open Group]

Hi,

I would like the standard POSIX date utility to receive an option to format
timestamps with modern RFC3339 format.

The GNU date utility seems to do this poorly, using the overly elaborate
pattern "...+00:00" instead of "...Z" for UTC timezone.

-- 
Cheers,
Andrew

Correction: Minutes of the 9th May 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All

The disposition for bug report 1817 was incorrect. Enclosed are that section of 
the corrected minutes (the full document is in the document register)

regards
Andrew
__

Minutes of the 9th May 2024 TeleconferenceAustin-1404 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 10th May 2024

{snip}

Bug 1817: lseek(2) - "size of a file" undefined Accepted as Marked
https://austingroupbugs.net/view.php?id=1817

This item is marked for TC1-2024

On page 965 line 32823 section fstatat(), change:
The value of the st_size member shall be set to the length of
the pathname contained in the symbolic link
to:
The value of the st_size member shall be set to the length of
the contents of the symbolic link

On page 1292 line 43059 section lseek(), change:
the file offset shall be set to the size of the file plus offset.
to:
the file offset shall be set to the size of the file (as would
be returned in st_size by the fstat() function) plus offset;
except that for block special files, it is unspecified whether
the offset is relative to the start of the file or to the
corresponding device's capacity in bytes.



On page 1293 line 43104 section lseek(), add fstat() to SEE ALSO. 

{snip}



Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Minutes of the 9th May 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of yesterday’s meeting
regards
Andrew
--

Minutes of the 9th May 2024 TeleconferenceAustin-1404 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 10th May 2024


Attendees:
Andrew Josey, The Open Group
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE SA OR
Geoff Clare, The Open Group
Eric Blake, Red Hat, The Open Group OR
   
Apologies
Tom Thompson, IEEE
Eric Ackermann, CISPA
Mark Ziegast, SHware Systems Dev

* General news

The general news is unchanged.

The IEEE Revcom committee met on May 6 to consider approval of draft 4.1.
We have yet to hear the result.
After approval we can moved forward to complete the frontmatter
and proceed to publication, and the html conversion.

The ISO/IEC ballot closes on June 28.

* Current Business

1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797

We will continue this item next time that Paul is available (expected in April).


Bug 1817: lseek(2) - "size of a file" undefined Accepted as Marked
https://austingroupbugs.net/view.php?id=1817

Proposed interpretation (review timer to start after approval of
issue 8), using draft 4.0 line numbers .

Interpretation response:
The standard states that the posix_getdents() function starts reading
at the current file offset in the open file description associated
with fildes, and conforming implementations must conform to this.
However, concerns have been raised about this which are being
referred to the sponsor.

Rationale:
Elsewhere the standard makes allowances for implementations where
directory streams are not implemented using a file descriptor, but
this was not extended to the new posix_getdents() function when it
was added.

Notes to the Editor (not part of this interpretation):

After page 920 line 31407 section fdopendir(), add a new paragraph:

If the file descriptor specified by fd is associated with an
open file description on which posix_getdents() has previously
been used, or for which any associated file descriptor is already
associated with a directory stream, the behavior is unspecified.

After page 1567 line 52616 section posix_getdents():
The behavior is unspecified if lseek() is used to set the file
offset to a value other than zero or a value returned by a
previous call to lseek() on the same open file description.

add these sentences:
The behavior is unspecified if calls to posix_getdents() are
made on different file descriptors that refer to the same open
file description (for example, before and after a file descriptor
is inherited across fork() or the exec family of functions, or
is duplicated using dup() or fcntl()), unless lseek() is used
to set the file offset to zero in between the calls to
posix_getdents(). A single exception to this condition is that
after a call to fork(), either the parent or child (but not
both) can continue processing the directory using posix_getdents().
Likewise, the behavior is unspecified if in between two calls
to posix_getdents() on one file descriptor, the file offset is
altered by a call made on a different file descriptor that
refers to the same open file description.


At page 1568 line 52626 section posix_getdents(), change:
If a sequence of calls to posix_getdents() is made that reads
from offset zero to end-of-file and a file is removed from or
added to the directory between the first and last of those
calls, whether the sequence of calls returns an entry for that
file is unspecified.
to:
If a sequence of calls to posix_getdents() is made that reads
from offset zero to end-of-file and a directory entry is removed
from or added to the directory between the first and last of
those calls, whether the sequence of calls returns that directory
entry is unspecified.

After page 1571 line 52771 section posix_getdents(), add a new
paragraph to RATIONALE:
The restrictions on the use of different file descriptors that
refer to the same open file description are needed in order to
enable implementations where directory streams are not implemented
using a file descriptor to maintain some internal state related
to a particular file descriptor.

At page 1858 line 61304, section readdir(), change:
If a file is removed from or added to the directory after the
most recent call to opendir() or rewinddir(), whether a subsequent
call to readdir() returns an entry for that file is unspecified.
to:
If a directory entry is removed from or added to the directory
after the most recent call to opendir() or rewinddir(), whether
a subsequent call to readdir() on that directory stream returns
that directory entry is unspecified. For all other directory
entries in the directory that existed at the time the directory
stream w

Re: Fediverse for May topic

[Austin Godber via PLUG-discuss]

> You can run your own instance. At least one person on this list does that.

I have been running a Mastodon instance with a small group of AZ people at
https://az.social since Nov 2022, it's open for registrations if any AZ
folks are interested in joining.  I've since added a Lemmy instance (like
Reddit) at https://lemmy.az.social.  And I also run a Fediverse public user
profile search engine at https://western.social.  Initially some friends
and I found it hard to find people in the Fediverse, so we started crawling
public profiles so we could better find people to follow.

I've been considering running other services, but I've got a lot of other
things keeping me busy so I haven't yet.

Austin

On Thu, May 9, 2024 at 11:45 AM der.hans via PLUG-discuss <
plug-discuss@lists.phxlinux.org> wrote:

> Am 09. May, 2024 schwätzte Stephen Partington via PLUG-discuss so:
>
> moin moin Stephen,
>
> Yes. ish. :)
>
> Most of the Fediverse is using ActivityPub for server to server
> communication, so they know how to subscribe to and to share content with
> each other.
>
> Some Fediverse services offer RSS, so that's also an option for read-only
> subscription.
>
> You can run your own instance. At least one person on this list does that.
>
> There are also several general use instances and many, many shared
> interest instances. For instance, I use https://FLOSS.social/, which is a
> shared interest instance for people interested in Free Software.
>
> There are Fediverse projects specializing in short posts, picture
> sharing, video sharing, live streaming, link sharing, book club, event
> coordination and more.
>
> ciao,
>
> der.hans
>
> > So the idea is to be able to join your own or your buddy's social media
> > site, and then it syncs to others. all the content and activity is still
> on
> > that main server, but people from other servers can still subscribe to
> you
> > from wherever they are logged in. and then this subscription is handed
> back
> > and forth when called/requested between the different services.
> >
> > So your feed can pull content from just one server or 50 depending on
> your
> > subscriptions. but you still only have to deal with one social location.
> a
> > lot like a really pretty and interactive RSS feed, so you can use this
> for
> > news info, social updates whatever you want.
> >
> > On Thu, May 9, 2024 at 8:59 AM Keith Smith via PLUG-discuss <
> > plug-discuss@lists.phxlinux.org> wrote:
> >
> >> Hi Went to what I think is the "main" website and it said:
> >>
> >> Fediverse social network differs from mainstream platforms (Facebook,
> >> Twitter, Instagram, Pinterest, etc). Mainstream platforms concentrate
> >> millions of users on one website, where they control all the
> >> decision-making, enforce censorship, and hoard users' data for
> >> commercial profit and spying. Fediverse platforms, on the other hand,
> >> are developed by a community of people from all over the world,
> >> independent from any company or official institution. You are free to
> >> register on any Fediverse website you like. You can choose the person
> >> who will be in charge of your data - the administrator of your server.
> >> If you have technical knowledge, you can administrate your own server
> >> for your friends and family, connecting with thousands of other
> >> independent servers across the web. Fediverse is an autonomous universe
> >> where power and data are decentralized and scattered across multiple
> >> lands.
> >>
> >>
> >> So how is Fediverse used?  I am not active on any Social Media how
> >> do I leverage this service?
> >>
> >> Thanks!!
> >> Keith
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 2024-05-08 23:37, der.hans via PLUG-discuss wrote:
> >>> moin moin,
> >>>
> >>> I updated my Fediverse talk for LinuxFest Northwest, but we had some
> >>> technical difficulties and I didn't get through the whole thing, so I'm
> >>> reprising it for tomorrow's PLUG meeting.
> >>>
> >>> "Mastodon and the Fediverse: Decentralized Social Networking and
> >>> Services"
> >>>
> >>> Still in Big Blue Button at 19:00.
> >>>
> >>> https://lufthans.bigbluemeeting.com/plu-yuk-7xx
> >>>
> >>> https://floss.social/@FLOX_advocate/112409734846295432
> >>>
> >>> Stammtisch is a week from Tuesday at Boulders on Southern, also at
>

Re: Preventing other software from linking against MacPorts libraries

[Austin Ziegler]

One could also `sudo port deactivate …` the ports which are problematic. I
occasionally have to do this with certain Rust tools through `cargo build`
(especially if they use libiconv).

-a

On Thu, May 9, 2024 at 4:13 PM Dave Horsfall  wrote:

> > > Sometimes I just end up deleting /opt/local to get it to build and
> > > then re-install MacPorts, which can be painful or at least tiresome.
>
> The question has since been answered, but what was wrong with merely
> renaming /opt/local temporarily?  That's what I would've done...
>
> -- Dave
>


-- 
Austin Ziegler • halosta...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1817 
== 
Reported By:kre
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1817
Category:   System Interfaces
Type:   Omission
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Robert Elz 
Organization:
User Reference:  
Section:XSH 13  lseek 
Page Number:1292-3 
Line Number:43059, 43061-2 43070-2 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1817#c6777 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2024-02-25 05:34 UTC
Last Modified:  2024-05-09 15:12 UTC
== 
Summary:lseek(2) - "size of a file" undefined
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-02-25 05:34 kreNew Issue
2024-02-25 05:34 kreName  => Robert Elz  
2024-02-25 05:34 kreSection   => XSH 13  lseek   
2024-02-25 05:34 krePage Number   => 1292-3  
2024-02-25 05:34 kreLine Number   => 43059, 43061-2
43070-2
2024-04-11 11:12 geoffclare Note Added: 0006745  
2024-04-11 12:53 kreNote Added: 0006746  
2024-05-02 16:00 eblake Note Added: 0006775  
2024-05-09 15:10 geoffclare Note Added: 0006777  
2024-05-09 15:12 geoffclare Interp Status => --- 
2024-05-09 15:12 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1817#c6777
2024-05-09 15:12 geoffclare Status   New => Resolved 
2024-05-09 15:12 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1830 
== 
Reported By:lacos
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1830
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   László Érsek 
Organization:
User Reference:  
Section:pwrite, write 
Page Number:? 
Line Number:? 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-03 06:55 UTC
Last Modified:  2024-05-03 06:55 UTC
== 
Summary:off-by-one error regarding offset maximum
Description: 
(Sorry for not providing page and line numbers; I've not been following
POSIX development for a good while, and don't remember where I could
download a PDF version.)

The open() specification contains:

"The largest value that can be represented correctly in an object of type
off_t shall be established as the offset maximum in the open file
description."

The write() / pwrite() spec states the following, *consistently* with the
open() spec:

"""
[EFBIG]
The file is a regular file, nbyte is greater than 0, and the starting
position is greater than or equal to the offset maximum established in the
open file description associated with fildes.
"""

However, the write() / pwrite() spec also states the following,
*inconsistently* with the above references:

"For regular files, no data transfer shall occur past the offset maximum
established in the open file description associated with fildes."

This last statement is not strict enough; a data transfer even precisely
*at* the offset maximum, not just past it, should not occur. Otherwise, the
resultant offset will not be representable in off_t.

Footnote 1: for simplicity, assume that off_t is identical to int8_t; in
that case, the off_t maximum, hence the offset maximum, is 127. If we
allowed

  lseek(fd, 127, SEEK_SET);
  write(fd, "X", 1);

to succeed, then the next call to

  lseek(fd, 0, SEEK_CUR);

would have to fail with -1/EOVERFLOW. The EFBIG description in write()
actually forbids the above write() from succeeding -- correctly so --,
however the "no data transfer shall occur past the offset maximum" language
would permit this write() to succeed (because the data transfer would occur
precisely *at* the offset maximum), and that's what's wrong.)

Footnote 2: this is an interesting difference from pointer arithmetic in
the C standard. In, C, the following is valid:

  char x[10];
  char *p;

  p = x + 9;
  *p++ = 'X';
  p;

That is, pointing one past the array is valid -- evaluating such a pointer
is valid (while dereferencing it is undefined behavior). In contrast, with
the file position, we cannot point one past the max representable off_t,
and therefore we cannot transfer to/from the byte in the file *at* the max
representable off_t.
Desired Action: 
In write()/pwrite(), change

"For regular files, no data transfer shall occur past the offset maximum
established in the open file description associated with fildes."

to

"For regular files, no data transfer shall occur at or past the offset
maximum established in the open file description associated with fildes."

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-03 06:55 lacos  New Issue
2024-05-03 06:55 lacos  Name  => László Érsek 
2024-05-03 06:55 lacos  Section   => pwrite, write   
2024-05-03 06:55 lacos  Page Number   => ?   
2024-05-03 06:55 lacos  Line Number   => ?   
==

[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1817 
== 
Reported By:kre
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1817
Category:   System Interfaces
Type:   Omission
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XSH 13  lseek 
Page Number:1292-3 
Line Number:43059, 43061-2 43070-2 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-02-25 05:34 UTC
Last Modified:  2024-05-09 15:10 UTC
== 
Summary:lseek(2) - "size of a file" undefined
== 

-- 
 (0006777) geoffclare (manager) - 2024-05-09 15:10
 https://austingroupbugs.net/view.php?id=1817#c6777 
-- 
On page 965 line 32823 section fstatat(), change:
The value of the st_size member shall be set to the
length of the pathname contained in the symbolic link
to:  
The value of the st_size member shall be set to the
length of the contents of the symbolic link

On page 1292 line 43059 section lseek(), change:
the file offset shall be set to the size of the file plus
offset.
to:
the file offset shall be set to the size of the file (as would
be returned in st_size by the fstat() function) plus
offset; except that for block special files, it is unspecified
whether the offset is relative to the start of the file or to the
corresponding device's capacity in bytes.

On page 1293 line 43104 section lseek(), add fstat() to SEE ALSO. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-02-25 05:34 kreNew Issue
2024-02-25 05:34 kreName  => Robert Elz  
2024-02-25 05:34 kreSection   => XSH 13  lseek   
2024-02-25 05:34 krePage Number   => 1292-3  
2024-02-25 05:34 kreLine Number   => 43059, 43061-2
43070-2
2024-04-11 11:12 geoffclare Note Added: 0006745  
2024-04-11 12:53 kreNote Added: 0006746  
2024-05-02 16:00 eblake Note Added: 0006775  
2024-05-09 15:10 geoffclare Note Added: 0006777  
==

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

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:663ce73799...@opengroup.org
DTSTAMP:20240509T150944Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240509T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 16-May-2024 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\nAll calls are a
 nchored on US time\n\nTopic: Austin Group teleconference\n
 ---\nAudio conference information\n---
 \n\nYou are invited to
  a WEBEX meeting. \n
DTSTART;TZID=America/New_York:20240516T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240509T110944Z
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: [Starlink] The "reasons" that bufferbloat isn't a problem

[Jeremy Austin via Starlink]

On Tue, May 7, 2024 at 11:11 AM Dave Taht via Starlink <
starlink@lists.bufferbloat.net> wrote:

> The RFC is very plausible but the methods break down in multiple ways,
> particularly with wifi.
>

Dave, can you elaborate more on the failures? Are these being researched or
addressed in the current trials, in your opinion?

Jeremy
___
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

Re: Call for proposals for the next governance meeting

[Austin Shafer]

On 5/7/24 4:04 AM, Jonas Ådahl wrote:
> On Wed, Apr 17, 2024 at 11:09:09AM -0400, Austin Shafer wrote:
>> Hi all,
>>
>> Not a protocol, but I think it would be good to discuss the possibility
>> of regular Wayland Governance meetings at a decided frequency. Currently
>> meetings are scheduled on demand to discuss a particular subject or
>> protocol, but I believe routine discussions could be very beneficial in
>> progressing protocol designs.
>>
>> One issue we currently have is that many protocol proposals turn into
>> multi year endeavors. Explicit Sync [1] is a recent example of this
>> which was merged after two years, and surface group transactions [2] are
>> still in review after four years. While these proposals are full of
>> excellent discussions, if the time is measured in years I think that
>> means there's room for improvement regarding how long it takes us to
>> make forward progress. It can also be unclear who is interested in a
>> protocol and for what reasons, or who depends on it to ship features in
>> a particular release.
>>
>> As more distros switch to Wayland by default, I believe having more
>> frequent/routine meetings would be a good investment to avoid
>> indefinitely blocking new desktop features. Less formal conversations
>> can also provide opportunities to see how implementations are
>> progressing, ask for reviews, and get an idea of when protocols might be
>> ready to land.  All of these could be beneficial for handling growing
>> pains: more Wayland users means more feature requests. My hope is this
>> could reduce the social burden of proposing a protocol or tracking its
>> progress.
>>
>> That being said there are many open questions to answer:
>> - Is there interest in formally making meetings at a certain time
>>   interval, would the community find this useful?
> 
> Personally I wouldn't mind making them reoccurring at an interval, but I
> do see it being somewhat difficult to achieve.
> 
> So far each meeting has had a topic and someone who has been wanting to
> lead the meeting. How do you imagine this would work; would we have
> someone assigned to handle this, or a rotating position, or ad-hoc
> depending on the topic?

I'm happy to assign myself to handling this since it is my proposal. We
could also rotate it or have the agenda item/topic owner lead discussion
about their particular item.

> 
>> - How to decide on a time? Poll before every meeting?
> 
> I see the point of why we'd want to poll, because different topics might
> bring different people, with different timezones, but I also see a
> problem with polling every time; it's a reoccurring administrative task
> that, and there is a risk that people will get tired of answering the
> same poll if it's asked of them too often.
> 
> Still, in advance whether there will be a quorum helps planning one's
> personal schedule, and a time poll could achieve this to some degree.
> 
>> - How frequent should the regular meetings be? Monthly? Biweekly?
> 
> Perhaps monthly, with any extra following the existing ad-hoc model, is
> a good start.
> 
>> - How far in advance would we decide on agenda/topics? Tentative agenda
>>   sent out a week before with a call for topics?
>> - Pain-points in the existing protocol approval process: would this help
>>   them?
>> - Should we track action items from the previous meeting and follow up
>>   on their status?
> 
> This sounds like agenda topics one would add.
> 
>> - Should there be "status updates"/pings for long-lived protocol proposals?
> 
> This is somewhat what the last meeting was about, a revival of the
> group transaction protocol proposal.
> 
>> - Possible agenda items for regular meetings. I have some initial ideas
>>   but would appreciate more suggestions if there are any pressing
>>   topics?
>>
>> Non-goals which I don't want to accidentally accomplish with this:
>> - Rush discussions or rush protocols out the door
>> - Force a schedule onto projects or contributors
>>
>> As always I'm open to any suggestions. I'm happy to drive the discussion
>> on this in the next governance meeting, and also shoulder the
>> organizational burden of doing these if we go forward with it.
> 
> Having meetings ad-hoc has the benefit of not adding a consistently
> reoccurring burden on peoples schedule, and if the interest for this is
> not big enough, an alternative could perhaps be to make it easier some
> how to schedule ad-hoc meetings.
> 
> Ideas for that could be a formal place to gather agenda topics and
> interest in participation, and som

Re: [AI] People with disabilities to get quotas in all trains irrespective of fare concessions - The Hindu

[Austin Pinto]

hi all.
as the topic of concession has come up, i want to ask a question insted of
opening a new topic.
we get concession for mumbai local train pass, do we also get concession on
mumbai local train which are AC?
how much % consession

On Tue, May 7, 2024 at 12:53 PM Rahul Gambhir 
wrote:

> People with disabilities to get quotas in all trains irrespective of fare
> concessions
>
>
> https://www.thehindu.com/news/national/differently-abled-passengers-to-get-quota-in-all-trains-irrespective-of-concession/article68142046.ece
>
> The Ministry of Railways has approved quotas for people with disabilities
> (PwDs) in all trains, irrespective of whether any concessional fare
> facility is available or not.
>
> According to railway sources, the PwD quota will be earmarked in all
> reserved Express/Mail trains, including Rajdhani, Shatabdi, Duronto,
> Humsafar, Gatimaan, and Vande Bharat express trains.
>
> According to the revised norms, the quota will be: four berths in Sleeper
> Class (two lower and two middle), four berths in Three Tier AC, 3E or 3A,
> (two lower and two middle), four berths in the Specially Designed Second
> Class Luggage cum Guard (SLRD) coaches of Garib Rath trains, four seats in
> reserved Second Class sitting and AC Chair Car in those trains which have
> more than two coaches of these classes, and four seats in Vande Bharat
> trains.
> Specially designed seats
>
> The sources added that two specially designed seats (Seat No. 40) will be
> available for PwDs in coaches C1 and C7 in the case of eight-car trains,
> and C1 and C14 in 16-car trains, along with an additional adjacent seat for
> an escort or attender in Vande Bharat Express trains.
>
> To avoid misuse of the provision, the facility of booking tickets under
> the PWD quota online will only be available to people who have been issued
> with Unique Identity Cards by Indian Railways. To book tickets at
> reservation counters, the facility will be extended on the production of a
> Unique Identity Card or the copy of the concessional certificate in the
> prescribed format.
>
> The Centre for Railway Information Systems, the IT arm of the railways,
> was told to modify its computerised reservation software to ensure the
> verification of Unique Idenitity Cards even in those trains where
> concessional fare facility is not available.
> Undecided on concessions for seniors
>
> In case both of the specially designed seats earmarked for PWDs in Vande
> Bharat express trains are booked, but one or both of the seats reserved for
> their accompanying escorts remained vacant, such vacant seat or seats will
> also be allotted to a passenger with a disability.
>
> Under the old guidelines, PWDs and their escorts were provided
> accommodation under the quota only in those trains which allowed booking
> tickets with fare concessions, the sources said. They added that no
> decision has been taken yet on restoring the rail travel concession to
> senior citizens and other categories of passengers who were given
> concessional fares before the pandemic.
>
>
>
>
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of
> the person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/01ef01daa04f%246229d460%24267d7d20%24%40gmail.com
> 
> .
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or whatever
with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [AI] Why do people say these things to the blind? And what can be done for the same?

[Austin Pinto]

only 1 thing can be done.
if some1 says something, you can ask them like for example
why will you get  punya by teaching me, you cant get  punya by teaching
some sighted person?
and so on.
On Tue, May 7, 2024 at 9:52 AM Cauvery Krishna 
wrote:

> These are some of the experiences had by one of my  students of which I
> don't have an answer. Could you please help me.
> 1. Di, I am a visually impaired  MBA student, pursuing MBA from an IIM. I
> was with a senior at the grocery store of our campus, i waited as the
> senior got ice cream for both of us. The shopkeeper said, "inko bolo kal
> aane k liye, kal meri taraf se mai inko kuch dunga. Ice cream ya juice kuch
> dunga meri taraf se." Which roughly translates to, "ask him to come
> tomorrow, I'll give him an ice cream or juice from my side." So the
> question is why would the shopkeeper have said the same? I am an MBA
> student, I was wearing clean clothes, I was holding a forty thousand rupees
> phone in one hand and a white stick in the other hand. I don't understand
> did he think I can't afford a Rs 50 ice cream? I am paying the equal amount
> of fees but upon my survey he never said anything like this to any of the
> sighted or non disabled students. Why was the ice cream ? For merely being
> blind?
> 2.  Di, one of my batchmates said, "how is the preparation for the exams
> going? Do one thing, come let me teach you, I'll get punya by teaching
> you." Why is it? Why can't people with blindness just exist? What is this
> attachment of punya if we help the blind we'll get punya? Are we humans or
> some divine entity. If you don't get punya by helping or teaching a sighted
> or a non disabled person then why punya from the blind?
> Please suggest how I can help my student, as clearly, she is in a lot of
> stress by these experiences.
> Regards.
> Cauvery She/her.
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of
> the person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAK%3DRgBA6sNW0T0EDWxdD-nYiB%2Byk3-koUU%2BMOeyq8KphZt%2BU-g%40mail.gmail.com
> 
> .
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or whatever
with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi_6pE0g4mFXVJZ%3DwhGOVeymEXjbGW_2xzoO6wsim-voog%40mail.gmail.com.

Re: [AI]

[Austin Pinto]

ya, this is the best way to do it in such a situation

On Mon, May 6, 2024 at 2:47 PM  wrote:

> Given that there’s limited sighted person available, I don’t see any other
> way of assisting more than 2 or 3 persons. Moreover, why should it be
> considered as undignified way? In comparison to bumping in to stuff and
> spilling things around, this is far dignified way of guiding group of
> visually challenged folks. Let others think whatever they want and at least
> for me it is not a bother.
>
>
>
> Vetri.
>
>
>
> *From:* accessindia@accessindia.org.in  *On
> Behalf Of *Cauvery Krishna
> *Sent:* Monday, May 6, 2024 11:57 AM
> *To:* accessindia@accessindia.org.in
> *Subject:* [AI]
>
>
>
> Question of dignity? There were three visually impaired students and one
> sighted volunteer, the sighted volunteer grabbed the hand of one VI student
> and asked  the other two to keep their hands on each other shoulders, asked
> the other two to walk behind the first one, essentially, forming a train. I
> would like to know from you all is it a dignified way? If not, what would
> be a dignified way to assist three VIs by one sighted volunteer? Thank you.
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of
> the person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAK%3DRgBAH0FFPxKZ1FknWo%3D3Pok4p1MrLfrvRvZQ%3D2W8N00e34g%40mail.gmail.com
> 
> .
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of
> the person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/004501da9f96%243d104c40%24b730e4c0%24%40gmail.com
> 
> .
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or whatever
with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi_DCrrbBJK2KCB%3D1HMMbBb-73NyirAKqWR1Hgp9zp1QUg%40mail.gmail.com.

[USRP-users] Re: Sharing one UHD device across multiple hosts

[Stuart Austin]

Perhaps consider having a virtual machine (VM) act as the go-between? The VM 
talks directly to the device via UHD, but then provides its own API that splits 
out the streams/sessions to clients running elsewhere. You'd have to write some 
code, of course; but presumably you could implement something similar to UHD, 
so the clients would appear to be talking to the device directly, other than 
some home-brew way of selecting the device/session.

Cheers
Stuart Austin

-Original Message-
From: Marcus D. Leech [mailto:patchvonbr...@gmail.com] 
Sent: Sunday, May 05, 2024 11:36 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Re: Sharing one UHD device across multiple hosts

On 05/05/2024 11:27, jmalo...@umass.edu wrote:
>
> Hello,
>
> I am wondering if it is possible to allow another host device to start 
> a session with an x410 after it already has a session with a different 
> host device. In other words, multiple devices sharing one USRP device 
> at the same time.
>
> I know it is possible to “hijack” a session to perform some mpm 
> functions, but I would like to stream separate channels on the x410 
> device across separate host devices.
>
>
I don't believe that there's any such feature built-in to UHD. The USRP 
N2xx has an "alternative stream destination" API, but
   that did not make it into future USRPs as far as I know.

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

ATB.com

[Austin Hook]

{I'm currently still using release version of 7.4}

{This may be of interest mainly to residents of Alberta, Canada}

ATB.COM -- (i.e. Alberta Treasury Branch) is a provincially owned bank in 
Alberta, Canada.  In general it is nicer, and friendlier to use than most 
big commercial banks.  Not so, anymore, with their web page.

In the past 6 months is has gotten more and more difficult to sign-on 
to with Firefox and OpenBSD, as they have tried to make their sites more 
and more bullet proof. 

Now, starting from atb.com it's hard to even get to where one signs into 
personal banking, and to where it requests a username and password.

It seems to go through an amazing number of redirects, and then gets hung 
up in the process.  Sometimes, tapping different cadences with lots of 
control-R or control-F5 sequences, I can get through.  It must be a matter 
of timing.

I guess it works better with other operating systems and/or browsers.  In 
fact I do have much better luck with Chromium + OpenBSD although not 
always.

I'd prefer to use Firefox, so long as it exists semi-independently of 
monsters like Google. 

So, if anyone is interested, perhaps it would be nice if we could qualify 
to the ATB web page design team, what doesn't work well for everybody, 
and if anything they are doing is beyond being reasonable.

I also wonder if anyone has problems with Firefox and other operating 
systems, accessing ATB.COM, and even getting to the personal sign in page.

Additionally, even getting that far, doesn't guarantee one actually can 
get beyond the next sequence of redirects, when signing in.  It only works 
about half the time, from that point.

An additional reason, for us Albertans, to try to keep ATB.COM from going 
outside the normal bounds of web site protection, and hence making it work 
only from certain operating systems and browsers, is that the Alberta 
Government has become so sold on their toy bank, and it's website 
developers, that they have recently decided to put that team in charge of 
all the website development for the government of Alberta, which means I 
won't even be able to access my health records -- the online ability to do 
that they are so proud of

Whew... apologies for that run on sentence, above.

Anyone game to help push the point?

Sure, this is not really just an OpenBSD project question, but the project 
does have it's origins here in Alberta 

One doesn't have to be a resident of Alberta to see the problem (try it) 
-- but I am curious if the trend towards using timing to allow access to 
web sites is going to become more and more common, and how to fight back.

Austin

Milk River, Alberta

Re: Call for proposals for the next governance meeting

[Austin Shafer]

On 4/23/24 5:41 PM, Sebastian Wick wrote:
> Personally I would say we could give it a go, but I don't believe that
> this will significantly change how long some protocols take to get
> merged. The group transaction is taking so long because the subsurface
> sync and desync modes together with content update queues are hard to
> get right and the protocol makes everything much worse. The color
> management protocol took so long because it evolved with our
> understanding of color and colorimetry which changed significantly
> over the years. Some protocols are just stuck because stakeholders
> can't agree and most of the time the problem is just time and
> priorities.

I definitely understand that some problems are hard and require thorough effort
to iterate through. Like I outlined earlier it's also a non-goal to rush
protocols out the door: if things need time then we should spend time and get it
right. Although some of the stuck situations come from a legitimate need for
more time to properly validate a solution, I think there's a lot of situations
where it's easy to go off thinking and accidentally never return to the
discussion table in a timely manner. Having habitual meetings gives us some
protections against accidentally letting months go by without making progress.

I also agree that it's worth a try, and we can see if the community finds it
useful and go from there. I think the odds are good these can be productive and
it seems like a valuable investment as Wayland becomes more popular.

Thanks,
Austin

> 
> On Wed, Apr 17, 2024 at 5:09 PM Austin Shafer  wrote:
>>
>> Hi all,
>>
>> Not a protocol, but I think it would be good to discuss the possibility
>> of regular Wayland Governance meetings at a decided frequency. Currently
>> meetings are scheduled on demand to discuss a particular subject or
>> protocol, but I believe routine discussions could be very beneficial in
>> progressing protocol designs.
>>
>> One issue we currently have is that many protocol proposals turn into
>> multi year endeavors. Explicit Sync [1] is a recent example of this
>> which was merged after two years, and surface group transactions [2] are
>> still in review after four years. While these proposals are full of
>> excellent discussions, if the time is measured in years I think that
>> means there's room for improvement regarding how long it takes us to
>> make forward progress. It can also be unclear who is interested in a
>> protocol and for what reasons, or who depends on it to ship features in
>> a particular release.
>>
>> As more distros switch to Wayland by default, I believe having more
>> frequent/routine meetings would be a good investment to avoid
>> indefinitely blocking new desktop features. Less formal conversations
>> can also provide opportunities to see how implementations are
>> progressing, ask for reviews, and get an idea of when protocols might be
>> ready to land.  All of these could be beneficial for handling growing
>> pains: more Wayland users means more feature requests. My hope is this
>> could reduce the social burden of proposing a protocol or tracking its
>> progress.
>>
>> That being said there are many open questions to answer:
>> - Is there interest in formally making meetings at a certain time
>>   interval, would the community find this useful?
>> - How to decide on a time? Poll before every meeting?
>> - How frequent should the regular meetings be? Monthly? Biweekly?
>> - How far in advance would we decide on agenda/topics? Tentative agenda
>>   sent out a week before with a call for topics?
>> - Pain-points in the existing protocol approval process: would this help
>>   them?
>> - Should we track action items from the previous meeting and follow up
>>   on their status?
>> - Should there be "status updates"/pings for long-lived protocol proposals?
>> - Possible agenda items for regular meetings. I have some initial ideas
>>   but would appreciate more suggestions if there are any pressing
>>   topics?
>>
>> Non-goals which I don't want to accidentally accomplish with this:
>> - Rush discussions or rush protocols out the door
>> - Force a schedule onto projects or contributors
>>
>> As always I'm open to any suggestions. I'm happy to drive the discussion
>> on this in the next governance meeting, and also shoulder the
>> organizational burden of doing these if we go forward with it.
>>
>> [1] 
>> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90
>> [2] 
>> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26
>>
>> Thanks!

Minutes of the 2nd May 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of yesterday’s teleconference
regards
Andrew
--
Minutes of the 2nd May 2024 TeleconferenceAustin-1403 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 3rd May 2024


Attendees:
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE SA OR
Eric Ackermann, CISPA
Geoff Clare, The Open Group
Andrew Josey, The Open Group
Tom Thompson, IEEE
Eric Blake, Red Hat, The Open Group OR
   
Apologies
Mark Ziegast, SHware Systems Dev

* General news

There will be no meeting on Monday May 6th.

The IEEE Revcom committee meets on May 6 to consider approval of draft 4.1.
After that we can moved forward to complete the frontmatter
and proceed to publication, and the html conversion.

The ISO/IEC ballot closes on June 28.

Andrew noted that the company review of X/Open Curses Issue 8 has
been announced and starts next week (informational only).
Draft at:
https://collaboration.opengroup.org/review-support/documents.php?action=show==56805

* Current Business

1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797

We will continue this item next time that Paul is available (expected in April).


Bug 1817: lseek(2) - "size of a file" undefined OPEN
https://austingroupbugs.net/view.php?id=1817

We continued on this item, notes are in the etherpad, and will
continue on the item next time.


Next Steps 
--

The next call is on:
  Mon 2024-05-06 NO MEETING
  Thu 2024-05-09 (WEBEX meeting - general bugs)
  Mon 2024-05-13 (WEBEX meeting - general bugs)
  

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew Josey    The Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Re: [Starlink] It’s the Latency, FCC

[Jeremy Austin via Starlink]

Comments inline.

[image: Company logo] <https://preseem.com/>
*Jeremy Austin*
Sr. Product Manager
*Preseem | Aterlo Networks*
Book a call: https://app.hubspot.com/meetings/jeremy548
1-833-773-7336 ext 718 <18337737336718> *|* 1-907-803-5422 <19078035422>
jer...@aterlo.com 


On Thu, May 2, 2024 at 5:48 PM Ulrich Speidel via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
> Which brings me back to the question of how important bandwidth is. The
> answer is: probably more important in the future. We're currently relying
> mostly on CDNs for video delivery, but I can't fail but notice the progress
> that's being made by AI-based video generation. Four or five years ago,
> Gen-AI could barely compose a credible image. A couple of years ago, it
> could do video sequences of a few seconds. Now we're up to videos in the
> minutes.
>
> If that development is sustained, you'll be able to tell your personal
> electronic assistant / spy to dream up a personalised movie, say an
> operatic sci-fi Western with car chases on the Titanic floating in space,
> and it'll have it generated in no time starring the actors you like. ETA:
> Around 2030 maybe?
>
> But these things will be (a) data-heavy and (b) aren't well suited for CDN
> delivery because you may be the only one to every see a particular movie,
> so you'll either need to move the movie generation to the edge, or you need
> to build bigger pipes across the world. I'm not sure how feasible either
> option is.
>



Why shouldn’t the advances in GPU, CPU and storage substitute for
bandwidth? Given how compact symbol libraries are today, why shouldn’t one
be able to generate this high quality, customized movie entirely locally,
streaming characters, backgrounds, and kinematics from a large library?
Preloading their library is how image generation, transcription, etc.
 works today. This surely must be less total real-time bandwidth than the
alternative, which pre-renders elsewhere. With each target customized,
there will be a little incentive to pre-render elsewhere.

Offset against this potential bandwidth savings — clearly the next step in,
say, audiobook generation — is that eventually we will want full
stereoscopic 360 environments a la Apple headsets. Plausibly this is in the
16k range at a minimum. The Vegas Sphere is approximately this resolution.

My $.02
Jeremy Austin

>
___
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

[1003.1(2016/18)/Issue7+TC2 0001830]: off-by-one error regarding offset maximum

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1830 
== 
Reported By:lacos
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1830
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   László Érsek 
Organization:
User Reference:  
Section:pwrite, write 
Page Number:? 
Line Number:? 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-03 06:55 UTC
Last Modified:  2024-05-03 06:55 UTC
== 
Summary:off-by-one error regarding offset maximum
Description: 
(Sorry for not providing page and line numbers; I've not been following
POSIX development for a good while, and don't remember where I could
download a PDF version.)

The open() specification contains:

"The largest value that can be represented correctly in an object of type
off_t shall be established as the offset maximum in the open file
description."

The write() / pwrite() spec states the following, *consistently* with the
open() spec:

"""
[EFBIG]
The file is a regular file, nbyte is greater than 0, and the starting
position is greater than or equal to the offset maximum established in the
open file description associated with fildes.
"""

However, the write() / pwrite() spec also states the following,
*inconsistently* with the above references:

"For regular files, no data transfer shall occur past the offset maximum
established in the open file description associated with fildes."

This last statement is not strict enough; a data transfer even precisely
*at* the offset maximum, not just past it, should not occur. Otherwise, the
resultant offset will not be representable in off_t.

Footnote 1: for simplicity, assume that off_t is identical to int8_t; in
that case, the off_t maximum, hence the offset maximum, is 127. If we
allowed

  lseek(fd, 127, SEEK_SET);
  write(fd, "X", 1);

to succeed, then the next call to

  lseek(fd, 0, SEEK_CUR);

would have to fail with -1/EOVERFLOW. The EFBIG description in write()
actually forbids the above write() from succeeding -- correctly so --,
however the "no data transfer shall occur past the offset maximum" language
would permit this write() to succeed (because the data transfer would occur
precisely *at* the offset maximum), and that's what's wrong.)

Footnote 2: this is an interesting difference from pointer arithmetic in
the C standard. In, C, the following is valid:

  char x[10];
  char *p;

  p = x + 9;
  *p++ = 'X';
  p;

That is, pointing one past the array is valid -- evaluating such a pointer
is valid (while dereferencing it is undefined behavior). In contrast, with
the file position, we cannot point one past the max representable off_t,
and therefore we cannot transfer to/from the byte in the file *at* the max
representable off_t.
Desired Action: 
In write()/pwrite(), change

"For regular files, no data transfer shall occur past the offset maximum
established in the open file description associated with fildes."

to

"For regular files, no data transfer shall occur at or past the offset
maximum established in the open file description associated with fildes."

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-03 06:55 lacos  New Issue
2024-05-03 06:55 lacos  Name  => László Érsek 
2024-05-03 06:55 lacos  Section   => pwrite, write   
2024-05-03 06:55 lacos  Page Number   => ?   
2024-05-03 06:55 lacos  Line Number   => ?   
==

[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1829 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1829
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:symlink() 
Page Number:2095 
Line Number:67093 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-02 16:48 UTC
Last Modified:  2024-05-02 16:52 UTC
== 
Summary:symlink() and terminating null bytes
== 

-- 
 (0006776) geoffclare (manager) - 2024-05-02 16:52
 https://austingroupbugs.net/view.php?id=1829#c6776 
-- 
Also on page 965 line 32824 section fstatat(), delete:not
including any terminating null byte 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-02 16:48 geoffclare New Issue
2024-05-02 16:48 geoffclare Name  => Geoff Clare 
2024-05-02 16:48 geoffclare Organization  => The Open Group  
2024-05-02 16:48 geoffclare Section   => symlink()   
2024-05-02 16:48 geoffclare Page Number   => 2095
2024-05-02 16:48 geoffclare Line Number   => 67093   
2024-05-02 16:48 geoffclare Interp Status => --- 
2024-05-02 16:52 geoffclare Note Added: 0006776  
==

[1003.1(2016/18)/Issue7+TC2 0001829]: symlink() and terminating null bytes

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1829 
== 
Reported By:geoffclare
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1829
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:symlink() 
Page Number:2095 
Line Number:67093 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-02 16:48 UTC
Last Modified:  2024-05-02 16:48 UTC
== 
Summary:symlink() and terminating null bytes
Description: 
The description of symlink() says the created symbolic link contains "the
string pointed to by path1".  Since a string by definition has a
terminating null byte, by a strict reading this implies the null is
included in the symbolic link, but that's not the intended requirement, nor
how systems behave.

Desired Action: 
On page 2095 line 67093 section symlink(), change:The
symlink() function shall create a symbolic link called path2
that contains the string pointed to by path1 (path2 is the
name of the symbolic link created, path1 is the string contained in
the symbolic link).to:The symlink()
function shall create a symbolic link called path2 that contains the
string pointed to by path1, excluding the terminating null byte.
(That is, path2 specifies the pathname of the symbolic link created;
path1 specifies the contents of the symbolic link.)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-02 16:48 geoffclare New Issue
2024-05-02 16:48 geoffclare Name  => Geoff Clare 
2024-05-02 16:48 geoffclare Organization  => The Open Group  
2024-05-02 16:48 geoffclare Section   => symlink()   
2024-05-02 16:48 geoffclare Page Number   => 2095
2024-05-02 16:48 geoffclare Line Number   => 67093   
2024-05-02 16:48 geoffclare Interp Status => --- 
==

[1003.1(2016/18)/Issue7+TC2 0001828]: Rationale is out of date

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1828 
== 
Reported By:nick
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1828
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   low
Status: New
Name:   Nick Stoughton 
Organization:
User Reference:  
Section:sys/stat.h 
Page Number:395 
Line Number:13468 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-05-02 16:23 UTC
Last Modified:  2024-05-02 16:23 UTC
== 
Summary:Rationale is out of date
Description: 
The rationale for sys/stat.h states

This version of the standard specifies the traditional encoding, in
recognition that
nearly 20 years after the first publication of this standard numeric file
modes are still in
widespread use by application developers, and that all conforming
implementations still use the
traditional encoding.


However, at this point we are around 36 years after the first publication,
and numeric file modes are still in widespread use.
Desired Action: 
on lines 13467-13468 (Issue 7 TC2) change

in recognition that nearly 20 years after the first publication ...

to

in recognition that many years after the first publication ...

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-05-02 16:23 nick   New Issue
2024-05-02 16:23 nick   Name  => Nick Stoughton  
2024-05-02 16:23 nick   Section   => sys/stat.h  
2024-05-02 16:23 nick   Page Number   => 395 
2024-05-02 16:23 nick   Line Number   => 13468   
2024-05-02 16:23 nick   Interp Status => --- 
==

[1003.1(2016/18)/Issue7+TC2 0001817]: lseek(2) - "size of a file" undefined

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1817 
== 
Reported By:kre
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1817
Category:   System Interfaces
Type:   Omission
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XSH 13  lseek 
Page Number:1292-3 
Line Number:43059, 43061-2 43070-2 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2024-02-25 05:34 UTC
Last Modified:  2024-05-02 16:00 UTC
== 
Summary:lseek(2) - "size of a file" undefined
== 

-- 
 (0006775) eblake (manager) - 2024-05-02 16:00
 https://austingroupbugs.net/view.php?id=1817#c6775 
-- 
https://github.com/util-linux/util-linux/blob/master/lib/blkdev.c#L92 is an
example of an #ifdef chain for several ioctl attempts that tries to get
block dev size across several systems, given the fact that neither st_size
nor lseek(SEEK_END) are universally reliable for the purpose. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-02-25 05:34 kreNew Issue
2024-02-25 05:34 kreName  => Robert Elz  
2024-02-25 05:34 kreSection   => XSH 13  lseek   
2024-02-25 05:34 krePage Number   => 1292-3  
2024-02-25 05:34 kreLine Number   => 43059, 43061-2
43070-2
2024-04-11 11:12 geoffclare Note Added: 0006745  
2024-04-11 12:53 kreNote Added: 0006746  
2024-05-02 16:00 eblake Note Added: 0006775  
==

Austin Group WEBEX +1-408-792-6300 PIN 668 216 233

[Single UNIX Specification via austin-group-l at The Open Group]

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:6633ac6114...@opengroup.org
DTSTAMP:20240502T150817Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240502T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group WEB
 EX +1-408-792-6300 PIN 668 216 233\nDate/Time: 13-May-2024 at 11:00 Americ
 a/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengroup.org
 /platform/single_unix_specification/events.php\n\nAll calls are anchored o
 n US time\n\nTopic: Austin Group teleconference\n-
 --\nAudio conference information\n
 ---\n\nYou are invited to a WEBEX 
 meeting. \n
DTSTART;TZID=America/New_York:20240513T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240502T110817Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group WEBEX +1-408-792-6300 PIN 668 216 233
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

Minutes of the 29th April 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of the Monday meeting this week
regards
Andrew
-

Minutes of the 29th April 2024 TeleconferenceAustin-1402 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 1st May 2024


Attendees:
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE SA OR
Eric Blake, Red Hat, The Open Group OR
Geoff Clare, The Open Group
Eric Ackermann, CISPA
Andrew Josey, The Open Group
Tom Thompson, IEEE
   
Apologies
Mark Ziegast, SHware Systems Dev

* General news

There will be no meeting on Monday May 6th.

The ISO/IEC ballot closes on June 28.

The IEEE Revcom committee meets on May 6 to consider approval of draft 4.1.

* Current Business

1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797

We will continue this item next time that Paul is available (expected in April).

Bug 1816: daylight, timezone, tzname do not work with location-based TZ 
Accepted as Marked
https://austingroupbugs.net/view.php?id=1816
This item is tagged for TC1-2024.

 DESCRIPTION page 454 line 15841, change XSI to OB XSI.

line 15843, change CX to OB CX.

 FUTURE DIRECTIONS page 454 line 15856, change "None" to:
The variables daylight, timezone, and tzname are planned to be
removed in a future version of this standard, as they have
unspecified values unless the environment variable TZ is of the
second format.

daylight SYNOPSIS page 801 line 27445, change XSI to OB XSI.

strptime DESCRIPTION page 2160 lines 70602-70606: add OB shading
to "If this name matches ... shall be set to 0."

timezone SYNOPSIS page 2279 line 74382, change XSI to OB XSI.
Also remove the "()" after timezone in the page heading.

tzset SYNOPSIS page 2310

line 75167: change XSI to OB XSI
line 75169: change CX to OB CX
line 75170: add CX margin marker

tzset DESCRIPTION page 2310

lines 75175-75178 add OB margin marker and shading

line 75175: Prepend "If the value of TZ is of the second format,"

line 75178: change "as described in XBD Chapter 8 (on page 167)"
to "as described for the second TZ format in XBD Section 8.3 (on
page 174)"

line 75179: change XSI to OB XSI

line 75179: Also prepend "If the value of TZ is of the second format,"

Line 75182: Append the following paragraph:

[OB]If the value of TZ is not of the second format, the tzset()
function shall set the array elements of the external variable
tzname to point to unspecified string values[/OB]

[OB XSI]and shall set the external variables daylight and
timezone to unspecified values.[/OB XSI]

line 75183: change XSI to OB XSI

line 75199 (APPLICATION USAGE) Append the following paragraph:
The values of the variables daylight, timezone, and tzname can
only be relied upon to reflect the local timezone information
if the environment variable TZ value is of the second format.
Applications should use the tm_zone member of the tm structure
instead of tzname and the tm_gmtoff member instead of timezone.
When using tm_zone and tm_gmtoff there is no need for the
information that is available in daylight.

page 2311 line 75207 (tzset() FUTURE DIRECTIONS), change "None" to:
The variables daylight, timezone, and tzname are planned to be
removed in a future version of this standard, as they have
unspecified values unless the environment variable TZ is of the
second format.


page 2311 line 75210 (tzset() SEE ALSO), change:
XBD Chapter 8 (on page 167)
to:
XBD Section 8.3 (on page 174)


Bug 1817: lseek(2) - "size of a file" undefined OPEN
https://austingroupbugs.net/view.php?id=1817


We started on this item, and will continue on the item next time.


Next Steps 
--

The next call is on:
  Thu 2024-05-02 (WEBEX meeting - general bugs)
  Mon 2024-05-06 NO MEETING
  Thu 2024-05-09 (WEBEX meeting - general bugs)
  

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Re: [AI] Concession to persons with disabilities in vande Bharat trains

[Austin Pinto]

yes. there is a screen showing you km to cover and speed at which the train
is going along with some info.
i travel on konkan line a lot and there is no concession in Vande Bharat
and Shatabdi
Shatabdi was in second chair car this was before covid i remember.
but Vande Bharat was last year.

On Wed, May 1, 2024 at 6:55 PM BHAWANI SHANKAR VERMA 
wrote:

> yes, it should be raised with railway board commercial section or with
> CCPD or department of disability afairs. vande bharat is a premium train
> service. we don't demand concession but we demand attention. I also
> traveled 2-3 times in vande bharat and faced simillar issue specially while
> returning from toilet to your seat in AC chair car. that is the reason I
> prefer to travel in regular trains.
>
>
>
> On 5/1/2024 4:46 PM, Payal Jethra wrote:
>
> Hi All,
>
> I travelled this morning from Ahmedabad to Mumbai Borivali & have been
> frequently travelling Mumbai Gujarat route. My observations-
>
> * Since there is no way to identify myself as a passenger with visual
> impairment while booking ticket, there is no awareness/alertness amongst
> the team of such a passenger.
> * I got to understand from fellow passengers that there is an
> indicator/display that shows the number of kilometers to be covered. We
> wouldn't be able to tell otherwise.
>
> * Until the ticket was checked, there was no way for me to identify
> attendants on duty. God to hear on the announcement that there are helpline
> number stickers stuck near doors.
>
> * Unlike airline staff, the Vand Bharat team is yet to be trained to
> assist with getting off. The train hault at Borivali station is only 2
> minutes & I was lucky to have other passengers wheel down my bag onto the
> platform.
>
> So, when we do write to them  we'd want to keep some of these & other
> points in mind.
>
> Regards,
> Payal Jethra
>
>
> On Tue, Apr 30, 2024 at 6:29 PM BHAWANI SHANKAR VERMA <
> bsvermad...@gmail.com> wrote:
>
>> Concession is available in shatabdi chair car, rajdhani AC3 75% of the
>> fair will be charged. No concession available in vande bharat, garibrath,
>> janshatabdi, hamsafar and duranto trains.
>>
>>
>> On 4/30/2024 3:53 PM, george.abrah...@gmail.com wrote:
>>
>> No concession on Vande Bharat, Shatabdi, Rajdhani trains. Concessions
>> available only for Totally Blind persons. Please correct me if I am wrong!
>>
>>
>>
>> *From:* accessindia@accessindia.org.in 
>>  *On Behalf Of *Radio Udaan
>> *Sent:* 30 April 2024 14:07
>> *To:* accessindia@accessindia.org.in
>> *Subject:* Re: [AI] Concession to persons with disabilities in vande
>> Bharat trains
>>
>>
>>
>>
>>
>> Hello Ajay and all,
>>
>> I hope this email finds you well. I wanted to bring to your attention
>> that there seems to be neither any concession nor any quota in seat booking
>> for Vande Bharat.
>>
>> I have taken the initiative to file a petition regarding this matter in
>> the CCPD office. Let's wait and watch how things progress from here.
>>
>> Best regards,
>>
>> Danish Mahajan
>>
>>
>>
>> On Tue, Apr 30, 2024 at 7:25 AM Rahul Bhatia 
>> wrote:
>>
>> No concession is available on vande bharat train as of now. At least some
>> persentage of concession must be provided
>>
>>
>>
>> On Tue, 30 Apr, 2024, 5:55 am Himanshu Ranjan, <
>> sudhanshuranjan98...@gmail.com> wrote:
>>
>> No, Duronto Express trains do not offer concessions to physically
>> challenged passengers
>> but, Garib Rath Express trains reserve two lower and two upper berths for
>> people with disabilities (PWDs) on a first-come, first-served basis.
>> However, PWDs must have to pay the full fare for this facility.
>>
>> Thanks,
>>
>> Himanshu.
>>
>>
>>
>> On Mon, 29 Apr, 2024, 10:59 pm Mohib Anwar Rafay, 
>> wrote:
>>
>> I think Doranto and Garibrath also don't provide any concession for blind
>> passengers.
>>
>>
>>
>> On Mon, Apr 29, 2024 at 10:43 PM Himanshu Ranjan <
>> sudhanshuranjan98...@gmail.com> wrote:
>>
>> Hi sir,
>>
>> Vande Bharat does not provide any concession for persons with disability.
>>
>> It just offers full ticket.
>>
>> For more details you can check out this official PDF available on IRCTC
>> site:
>>
>>
>> https://contents.irctc.co.in/en/Salient%20Features%20of%20Vande%20Bharat%20Train.pdf
>>
>> Thanks,
>>
>> Himanshu.
>>
>>
>>
>> On Mon, 29 Apr, 2024, 9:37 pm Ajay Minocha, 
>> wrote:
>>
>> Hi everyone, this query is little bit urgent
>>
>> I wanted to enquire if someone has been successful to avail concession
>> while travelling through vande Bharat trains
>>
>> If yes then what is the percentage of concession that person with
>> disabilities are eligible for? Thanks in advance
>>
>> Ajay
>>
>> --
>> Disclaimer:
>> 1. Contents of the mails, factual, or otherwise, reflect the thinking of
>> the person sending the mail and AI in no way relates itself to its veracity;
>>
>> 2. AI cannot be held liable for any commission/omission based on the
>> mails sent through this mailing list..
>>
>>
>> Search for old postings at:
>> 

Re: finding callers key in svc

[Steve Austin]

I believe the PSW will be in the PRB rather than the SVRB; the registers
will be in the SVRB.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Erik Janssen
Sent: Tuesday, April 30, 2024 6:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: finding callers key in svc

I must be doing something wrong, because if I do that it indicates key 0. I
was expecting key 9 somewhere...

On Tue, 30 Apr 2024 08:50:13 -0500, Wayne Driscoll
 wrote:

>If you are in a Type 2, 3 or 4 SVC, the PSW at the time of the SVC
>instruction is in the SVRB whose address is in R5 upon entry, that is
>the RBOPSW you would want to interrogate. Your code is looking at the
>PSW at the time the callers RB was created, mostly via a LINK or ATTACH
>SVC, since it was a problem program.
>Wayne Driscoll
>Note: all opinions are strictly my own.
>
>On Tue, Apr 30, 2024 at 4:02 AM Erik Janssen <
>062c999269e8-dmarc-requ...@listserv.ua.edu> wrote:
>
>> 
>> >
>> >As to the initial question, as pointed out, it depends on the type
>> >of the
>> SVC. The SVC owner knows what type it is (because they defined it)
>> and can look in the right place for that type of SVC, just as they
>> look in the right place for the caller's regs (for which the answer
>> is different than the psw/key, but similarly depends on the type of the
>> SVC.
>> >
>> 
>>
>> I had the idea that this code in the SVC would give me the key the
>> SVC caller was executing in:
>>
>> USING RBBASIC,R5  POINT TO REQUEST BLOCK
>> L R7,RBLINK   LOAD CALLER RB IN REG 7
>> DROP  R5  DROP SVC RB MAPPING
>> USING RBBASIC,R7  AND NOW MAP CALLER RB
>> L R1,RBOPSW   GET CALLER PSW AND PUT IN REG 1
>> N R1,=X'00F0' ONLY PSW KEY
>> SRL   R1,16   SHIFT TO 00K0
>> STR1,KEY  STORE CALLER KEY
>> DCH'0'FORCE ABEND
>>
>> However, when I call this SVC from an problem program the switches to
>> key
>> 9 before the call:
>>
>>  SPKA  X'90'(0)  SWITCH TO KEY 9
>>  SVC   255
>>
>> I see that R1 has a value of x'0080' (key 8) at the time of the
>> abend, where I was expecting x'0090'.
>> Is see that it is possible that there are more request blocks. I'm I
>> not looking at the right one, and if so, how do you know if you
>> reached the top RB, or is my approach really wrong?
>>
>> Kind regards,
>>
>> Erik Janssen.
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>>
>
>
>--
>Wayne Driscoll
>Software Engineer | Mainframe Software Division Broadcom Software
>
>*Office: *630-300-1931* Mobile:* 630-247-1632
>wayne.drisc...@broadcom.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: release process: typescript SDK?

[Austin Bennett]

@Robert Bradshaw  -- this seems sensible.  I don't
have the relevant NPM credentials, so am unable to address myself.

Having manual steps in the release process, and esp. not keeping all SDKs
up-to-date seems worth addressing.

On Wed, Apr 17, 2024 at 8:29 AM Danny McCormick 
wrote:

> Probably the easiest way for this to happen is for @Robert Bradshaw
>  to get the token set up as a secret (should be
> quick) and then Austin to take the workflow forward.
>
> In the past to get secrets added, Infra has asked that I (a) email
> r...@apache.org with the secret name and secret contents, and (b) opened
> a JIRA to externally track progress -
> https://issues.apache.org/jira/browse/INFRA-25009
>
> On Wed, Apr 17, 2024 at 11:24 AM Austin Bennett  wrote:
>
>> I don't mind doing, esp. if nobody is eager to handle/prioritize the push
>> artifact in near-term.  If I'm to do, let's connect off-list for
>> token/creds.
>>
>> Furthermore, I agree that getting RCs as part of the overall
>> release/validation process would be a nice addition.
>>
>> On Tue, Apr 16, 2024 at 2:43 PM Robert Bradshaw via dev <
>> dev@beam.apache.org> wrote:
>>
>>> Correct, I've just been pushing these manually, and lately there haven't
>>> been many changes to push. I'm all for getting these set up as part of the
>>> standard release process.
>>>
>>> On Tue, Apr 16, 2024 at 1:22 PM Danny McCormick <
>>> dannymccorm...@google.com> wrote:
>>>
>>>> I've never published npm artifacts before, but I imagine the hardest
>>>> part is getting the credentials set up, then it is probably very easy to
>>>> set up a GitHub Actions workflow to publish
>>>> <https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages#publishing-packages-to-the-npm-registry>.
>>>> Who has done these releases in the past/has credentials for the npm
>>>> package? Maybe @Robert Bradshaw ? We will need a
>>>> token set up as a secret to automate this.
>>>>
>>>> I'll also note that we don't do any typescript validation today, and it
>>>> would be nice to publish RCs as part of this
>>>>
>>>> On Tue, Apr 16, 2024 at 4:11 PM Austin Bennett 
>>>> wrote:
>>>>
>>>>> Hi Beam Devs,
>>>>>
>>>>> Calling out it looks like our release process for apache-beam for
>>>>> typescript/npm is broken, seemingly the last published release was 2.49.0
>>>>> about 9 months ago.  The other languages look like they are publishing to
>>>>> expected locations.
>>>>>
>>>>> https://www.npmjs.com/package/apache-beam
>>>>>
>>>>> I noticed this since I was digging into security concerns raised by
>>>>> GitHub's dependabot across our repos [ ex:
>>>>> https://github.com/apache/beam-starter-typescript/security/dependabot ], 
>>>>> and
>>>>> towards getting our repos tidied.
>>>>>
>>>>> This leads me to believe we may want two distinct things:
>>>>> * update our release docs/process/scripts to ensure that we
>>>>> generate/publish all artifacts to relevant repositories.
>>>>> * Arrive at a process to more straightforwardly attend to security
>>>>> updates [ maybe we want these sent to dev list, or another distribution? ]
>>>>>
>>>>> From a very quick search, it did not look like we have scripts to push
>>>>> to npm.  That should be verified more thoroughly -- i haven't done a
>>>>> release before, so relevant scripts could be hiding elsewhere.
>>>>>
>>>>> Cheers,
>>>>> Austin
>>>>>
>>>>>
>>>>> NOTE:  everything with our main Beam repo specifically looks OK.  Some
>>>>> things discovered were on the other/supplementary repos, though I believe
>>>>> those are still worthwhile to attend to and support.
>>>>>
>>>>

Survey/Pulse: Beam on Flink/Spark/Samza/etc

[Austin Bennett]

Curious who all is using Beam on runners other than dataflow.

Please respond either on-list or to me directly ...  Mostly just curious
the extent of whether Beam is fulfilling its promise of runner
agnosticism.  Getting good data on that is hard, so anecdotes would be very
welcomed!