Re: tv_nsec

2023-01-19 Thread Nick Stoughton via austin-group-l at The Open Group
This issue is under discussion again in the C23 ballot resolution. The current POSIX standard has the type for tv_nsec as a long, and there is, to my knowledge, no proposal from the Austin Group to change it. Geoff's suggestion that perhaps changing this type might be acceptable is being taken as

Re: Can struct sockaddr_un.sun_path be a flexible array member?

2022-07-17 Thread Nick Stoughton via austin-group-l at The Open Group
Note that a flexible array member is not the same thing as a variable length array, and although both entered the standard in C99, previous versions allowed the FAM to be specified as an array of length 0. The C standard notes that: > In most situations, the flexible array member is ignored. In

Re: Is this the kind of "bug" you welcome reporting on one of your Standards (Shell Command Language)

2022-01-12 Thread Nick Stoughton via austin-group-l at The Open Group
Hi Mark; please feel free to ask on this list initially. Between us, we should be able to answer if it is (a), (b), or (c). In general, the POSIX shell was modeled on ksh88, but a few small changes were incorporated where David Korn (the author of ksh) said "Oh, that's a bug, I didn't mean it to

Re: Interpretation starting for a 30 day review (1440)

2021-10-29 Thread Nick Stoughton via austin-group-l at The Open Group
Just for reference, the C standard says: > If string is not a null pointer, the *system* function passes the string pointed to > by *string* to that command processor to be executed in a manner which the implementation shall > document; this might then cause the program calling system to behave in

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

2021-09-07 Thread Nick Stoughton via austin-group-l at The Open Group
The problem we were trying to address with this change is that bsd make (bmake) and GNU make both have a := operator, but they behave differently. We originally added ::= to match the gmake behavior. The idea with :::= is to match the bmake behavior. There is then some further confusion because

Re: [1003.1(2016/18)/Issue7+TC2 0001436]: make: add "-j max_jobs" option to support simultaneous rule processing

2021-04-27 Thread Nick Stoughton via austin-group-l at The Open Group
"Resolved" means that the working group came to a consensus over how to address the issue. "Accepted as marked" means that we agreed to the problem, but we did not resolve it as the original requester suggested ... there is alternate text in the bugnote identified in "Final Accepted Text".

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

2020-12-03 Thread Nick Stoughton via austin-group-l at The Open Group
If the value is 200112L, then the implementation of the monotonic clock is as specified in that version of the standard (where it was optional). If the value is 200809L, then the implementation of the monotonic clock is as specified in that version (where it was optional). And so on ... The

Re: Proposal to update reference to POSIX in the ISO C++ standard

2020-09-24 Thread Nick Stoughton via austin-group-l at The Open Group
ISO/IEC 9945:2009 including Corrigenda 1 (2013) and Corrigenda 2 (2017) is the current latest approved ISO standard. The Austin Group is in the process of revising this, with a publication date in 2022 expected. You state "Since the TCs are just lists of changes, not a complete document, ..."