Re: : can some POLL* values be marked obsolescent?

2024-08-08 Thread Philip Guenther via austin-group-l at The Open Group
I have no interest in deprecating MSG_OOB. Hat tip to Microsoft for the quality of the their docs on this...but WSAPoll != poll and code that aims to operate with both POSIX and WinSock is already absolutely full of remapping of names, types, and features to make some sort of base source work with

close-on-fork flag: existing implementation experience?

2024-08-03 Thread Philip Guenther via austin-group-l at The Open Group
So I've been looking at implementing close-on-fork support for OpenBSD and I'm wondering what existing implementation experience exists for this in a secure, mutli-user implementation. I know that, for example, per https://sortix.org/blog/posix-2024/ Sortix has implemented close-on-fork since 2013

Re: : can some POLL* values be marked obsolescent?

2024-08-02 Thread Philip Guenther via austin-group-l at The Open Group
On Fri, Aug 2, 2024 at 10:57 PM Niu Danny wrote: > BAND data corresponds to out-of-band data bit mask for > flags in `recv` and `send` calls, which in turn corresponds > to TCP Urgent packet bit, On what OS and where is that documented? > and it's a (legacy) mechanism > for dealing with head-of

: can some POLL* values be marked obsolescent?

2024-08-02 Thread Philip Guenther via austin-group-l at The Open Group
One of the pedagogical annoyances of poll() is the surfeit of POLL* values with distinctions that are not obviously apparent. Should I include POLLRDBAND in my events masks? How can I tell whether sockets generate priority data? It's kinda just handwaving. With the removal of STREAMS and the pu

Re: dladdr()'s second arg's type: when did it change to have an _t suffix?

2024-07-29 Thread Philip Guenther via austin-group-l at The Open Group
On Monday, July 29, 2024, Geoff Clare via austin-group-l at The Open Group < austin-group-l@opengroup.org> wrote: > Philip Guenther wrote, on 28 Jul 2024: > > > > Looking at https://austingroupbugs.net/view.php?id=993 I see the > > original proposal has the second argument's type as "Dl_info *", b

dladdr()'s second arg's type: when did it change to have an _t suffix?

2024-07-28 Thread Philip Guenther via austin-group-l at The Open Group
Looking at https://austingroupbugs.net/view.php?id=993 I see the original proposal has the second argument's type as "Dl_info *", but then in the final version it's been changed to "Dl_info_t *" and I don't see any discussion on the list or in the minutes from the calls about that change. Was that

Re: Minutes of the 30th May 2024 Teleconference

2024-06-01 Thread Philip Guenther via austin-group-l at The Open Group
On Fri, May 31, 2024 at 10:29 PM Andrew Josey via austin-group-l at The Open Group wrote: ... > Bug 1832: Add preadv() and pwritev() > https://austingroupbugs.net/view.php?id=1832 OPEN > > We believe that preadv() and pwritev() should be cancellation points. > Reading/writing to a file system acro

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

2024-05-17 Thread 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 (Februar

Re: [1003.1(2016/18)/Issue7+TC2 0001808]: Add option -a to getconf utility

2024-03-07 Thread Philip Guenther via austin-group-l at The Open Group
(Away from computer with credentials for the bug tracker, so just replying here) Format of the output isn’t defined (and differs substantially between at least FreeBSD and GNU utilities). Nothing prevents confstr() values from containing new lines, which makes the output ambiguous. (The implement

is waitid() intentionally not required to be async-signal-safe?

2022-12-17 Thread Philip Guenther via austin-group-l at The Open Group
I just noticed that waitid() is not included in the list of async-signal-safe interfaces, at least as of TC2. Was that an intentional decision or an oversight? Is there a known existing implementation where it isn't? (...or did I miss an existing bug about this?) Philip Guenther

Re: [1003.1(2016/18)/Issue7+TC2 0001440]: Calling `system("-some-tool")` fails (although it is a valid `sh` command)

2021-11-01 Thread Philip Guenther via austin-group-l at The Open Group
On Mon, Nov 1, 2021 at 12:02 PM Wayne Pollock via austin-group-l at The Open Group wrote: > On 11/1/2021 9:12 AM, Eric Blake wrote: > > On Sat, Oct 30, 2021 at 08:21:55PM -0400, Wayne Pollock via > austin-group-l at The Open Group wrote: > >> Is it guaranteed that on conforming systems nohup (and

Re: utilities and write errors

2021-06-28 Thread Philip Guenther via austin-group-l at The Open Group
On Mon, Jun 28, 2021 at 2:53 PM Vincent Lefevre via austin-group-l at The Open Group wrote: > On 2021-06-28 21:28:37 +0700, Robert Elz wrote: > > Date:Mon, 28 Jun 2021 15:48:33 +0200 > > From:Vincent Lefevre > > Message-ID: <20210628134833.ga46...@zira.vinc17.org> >

Re: behavior of printf '\x61'

2021-04-16 Thread Philip Guenther via austin-group-l at The Open Group
s unspecified". Portable code is > expected to use the work alike octal escape, not hex codes. > > On Fri, Apr 16, 2021 at 12:05 AM, Philip Guenther via austin-group-l at > The Open Group > wrote: > The general question is what requirements the standard put on the printf

Re: behavior of printf '\x61'

2021-04-15 Thread Philip Guenther via austin-group-l at The Open Group
Correction after off-list poke: FreeBSD's /usr/bin/printf and the printf builtin to /bin/sh both show "x61" On Thu, Apr 15, 2021 at 7:04 PM Philip Guenther wrote: > The general question is what requirements the standard put on the printf > utility when the format argument contains a \x or other

behavior of printf '\x61'

2021-04-15 Thread Philip Guenther via austin-group-l at The Open Group
The general question is what requirements the standard put on the printf utility when the format argument contains a \x or other unspecified backslash escape, but the example in the subject is a nice concrete example: what's required for or about the output of printf '\x61' ? 1003.1-2016 d

Re: [1003.1(2016/18)/Issue7+TC2 0001346]: Require support for CLOCK_MONOTONIC

2020-12-03 Thread Philip Guenther via austin-group-l at The Open Group
I agree with Robert on this. Bumping the value of these macros when there's no change to the specified behavior of the relevant functionality provides no benefit and is actively harmful to code being forward portable. Yes, this makes the text of the specification for these more complex, while bum

Re: net/if.h not connected to anything else in the spec

2020-12-02 Thread Philip Guenther via austin-group-l at The Open Group
On Wed, Dec 2, 2020 at 11:15 AM Schwarz, Konrad via austin-group-l at The Open Group wrote: > after some (moderate) digging, it seems like the interfaces documented in > net/if.h are not related to anything else defined in POSIX. > > > > To recap, the routines declared there provide a mapping bet

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Philip Guenther via austin-group-l at The Open Group
On Tue, Sep 1, 2020 at 1:20 PM Steffen Nurpmeso wrote: > Philip Guenther wrote in > : > |On Tue, Sep 1, 2020 at 6:22 AM Steffen Nurpmeso via austin-group-l at The > |Open Group wrote: > |> Robert Elz via austin-group-l at The Open Group wrote in > |> <9252.1598969...@jinx.noi.kre.to>: > |

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Philip Guenther via austin-group-l at The Open Group
On Tue, Sep 1, 2020 at 6:22 AM Steffen Nurpmeso via austin-group-l at The Open Group wrote: > Robert Elz via austin-group-l at The Open Group wrote in > <9252.1598969...@jinx.noi.kre.to>: > |Date:Tue, 1 Sep 2020 10:32:55 +0100 > |From:"Geoff Clare via austin-group-l at

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

2020-09-01 Thread Philip Guenther via austin-group-l at The Open Group
On Tue, Sep 1, 2020 at 5:40 AM Geoff Clare via austin-group-l at The Open Group wrote: > > -- > > (0004958) philip-guenther (reporter) - 2020-08-30 23:06 > > https://austingroupbugs.net/view.php?id=6 >