Re: raise(0) (was: Exit status 128)

e positive integer definition, so sign values wouldn't ever need 2 bits to represent negative, zero, and positive separately. On Tuesday, February 4, 2020 Geoff Clare wrote: Shware Systems wrote, on 03 Feb 2020: >> >> On Monday, February 3, 2020 Geoff Clare wrote: >> Shware Sy

Re: raise(0) (was: Exit status 128)

bruary 3, 2020 Geoff Clare wrote: Shware Systems wrote, on 03 Feb 2020: > >> C99 only specifies the behaviour of raise() and signal() for SIGABRT, >> SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM.  The behaviour for all >> other "sig" argument values is either imple

RE: raise(0) (was: Exit status 128)

d is fully defined. On Monday, February 3, 2020 Geoff Clare wrote: Shware Systems wrote, on 31 Jan 2020: > > Subject: Re: Exit status 128 [was: exit status for false should be 1-125] > > The value 128 is potentially special to platforms implementing > extensions, as it correspo

Re: Coordination on standardizing gettext() in future POSIX

, January 22, 2020 Joerg Schilling wrote: Shware Systems wrote: > This is not invention, as even Solaris allows you to turn it off with -s, as > you point out. It may work fine for the charsets/charmap files Solaris > historically provides to have escapes active as the default, but

Re: Coordination on standardizing gettext() in future POSIX

. Backwards compatibility with non-portable behavior was only a priority for Issue 6 On Wednesday, January 22, 2020 Joerg Schilling wrote: Shware Systems wrote: > This is not invention, as even Solaris allows you to turn it off with -s, as > you point out. It may work fine for the charsets/c

Re: Coordination on standardizing gettext() in future POSIX

, if an application makes use of localedef, that I see. As such, from a portability standpoint, I view not processing escapes as the safer alternative. On Tuesday, January 21, 2020 Joerg Schilling wrote: Shware Systems wrote: > My two cents, I'm more in favor of requiring the -e ala GNU, as a byte str

Re: Coordination on standardizing gettext() in future POSIX

My two cents, I'm more in favor of requiring the -e ala GNU, as a byte stream that may be an escape for the charset of one locale may be plain text in another locale, especially when the encoding of the escape char itself differs. This can complicate editing data files when a pot file is a

Re: A question on file flags after fork

. Changing from O_RDONLY to O_APPEND on the fly can be problematic to applications using pread(), for example, to access records from a database in parallel. On Tuesday, January 14, 2020 Ronald F. Guilmette wrote: In message <1676199645.11146898.1578981958...@mail.yahoo.com>, Shware Systems

RE: A question on file flags after fork

Short answer, because both file descriptors reference the same file description, ala a dup() being called, the SETFD modifying that description is visible in both processes through that file descriptor. A reopen() that attaches the reference in the child to a new description is needed for the

Re: Possible Header File Type Definition Clarifications

Re: in_addr_t and in_port_t I would think these were included in support of someone's Future Direction, perhaps some RFC or a single implementation, to make those aspects of a socket address opaque rather than byte arrays or types that may vary in width, endianness, or alignment according to

RE: revision of 9945

At this point the plan is to base POSIX Issue 8 on c17, not any c2x drafts subject to change. If anything, it appears the first c2x draft will probably be heavily influenced by what gets into next issue as extensions when POSIX_C_SOURCE is in effect. On Sunday, August 11, 2019 keld wrote: hi

Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files

Additionally, when GLOB_NOCHECK is in flags it is not expected to call stat() and return 0 paths if it does not exist. It is on the application to note the increase in count by 1 and compare the result for match to pattern to see if it needs to do a stat() seperately. One of the examples or

RE: Exporting an unset variable

Hit send accidentally, continuation inlined below On Sunday, July 7, 2019 Shware Systems wrote: I agree this could use some clarifying. Some may construe the synopsis that since name may be set directly with the =word portion, without this it is supposed to be set to a null string

RE: Exporting an unset variable

I agree this could use some clarifying. Some may construe the synopsis that since name may be set directly with the =word portion, without this it is supposed to be set to a null string and not stay unset; the same as if a name is $name referenced, unqualified by a test operator, without

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

Just being picky, re: "Arguments to find, pax, fnmatch() and glob() are others." at the bottom, which to me should be: "Arguments to exec('find',...), exec('pax',...), fnmatch() and glob() are others." as parameters of find and pax in scripts are shell words covered by the statement preceding

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

The backslash may or may not be removed per 2.13.1, since it is not followed by a shell or pattern special char. While the first paragraph there is explicit it is to be removed for the usual cases, whatever the following char is, the last paragraph has the wording only the specials are

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

the actual field splitting may have bugs I didn't investigate as thoroughly, but that is where differences would be introduced. Your example uses set -- *, not -- $@, so the behavior should be different, to begin with. On Friday, June 21, 2019 Chet Ramey wrote: On 6/21/19 8:50 PM, Shware Systems

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

... after ensuring it has a proper set of IFS seperator chars. On Friday, June 21, 2019 Shware Systems wrote: What? That's straight from list_rest_of_args() in subst.c, which is passed into string_list_dollar_at(), which runs it through quote_list(), same as if single quoted, after

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

What? That's straight from list_rest_of_args() in subst.c, which is passed into string_list_dollar_at(), which runs it through quote_list(), same as if single quoted, after ensuring it has a p. On Friday, June 21, 2019 Chet Ramey wrote: On 6/21/19 8:04 PM, Shware Systems wrote: > bash d

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

bash does, through use of make_bare_word() on each params[] value. Want to bet other shells don't have similar code? On Friday, June 21, 2019 Chet Ramey wrote: On 6/21/19 4:14 PM, Shware Systems wrote: > This follows from XCU 2.5.2, "* Expands to the positional parameters, > st

Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching

This follows from XCU 2.5.2, "* Expands to the positional parameters, starting from one, initially producing one field for each positional parameter that is set.", being construed as to treat each field as if surrounded by single quotes when the parameter is used outside a double quoted word

RE: [1003.1(2016)/Issue7+TC2 0001263]: Add ppoll( )

I vote leave it unchanged, to save having to reinit it each time through a loop... Use case for modifying it eases benchmarking stat computation, but most apps just need to know whether it returned due to timeout or not, I imagine. On Tuesday, June 18, 2019 Austin Group Bug Tracker wrote:

Re: getopts, OPTIND, and grouped options

I tend to agree, but since the initial and final values are numeric, and in the absence of any explicit allowance for any other data type, it goes without having to be stated the other sequence values are numeric also, and "next" is simply a post-increment. What is left as optimization is that

RE: getopts, OPTIND, and grouped options

Correction, sequence should be 2, 3, then 4 while exit status 0, and 5 with exit status 1. On Friday, June 14, 2019 Shware Systems wrote: My understanding is that while input switches may be concatenated, internally it should have OPTIND tracking each switch as if they were specified

RE: getopts, OPTIND, and grouped options

My understanding is that while input switches may be concatenated, internally it should have OPTIND tracking each switch as if they were specified separately. No skipping of index values should occur; when an OPTARG is advanced past this does not affect the count of how many switch letters

Re: shell `var=value function`

To me, it is one of the underspecified responsibilities of a standard utility implemented as a shell function to use an internal procedure that makes the current local state as if a subshell was forked to exec a utility on media, including with temporary exports, etc. When the shell function

Re: Bug 1228: allow shells to exclude "." and ".." from pathname expansions

wording allows enables some nominally valid workflows to succeed and so the desire is to have both be possible. On Friday, May 31, 2019 Chet Ramey wrote: On 5/31/19 1:35 PM, Shware Systems wrote: > To me this is a case where the logical model of shell globs has always been >

Re: Bug 1228: allow shells to exclude "." and ".." from pathname expansions

To me this is a case where the logical model of shell globs has always been buggy, as it relates to relative path specifications, so if something that fixes it is inventable, it's past time to get it implemented. While for many existing uses the issues discussed won't rear their head, leaving

Re: pthread_t and thrd_t

> > On Thu, Apr 18, 2019 at 8:46 AM Joel Sherrill > wrote: >> >> >> On 4/18/2019 4:31 AM, Geoff Clare wrote: >>> Shware Systems wrote, on 17 Apr 2019: >>>> On Wednesday, April 17, 2019 Geoff Clare wrote: >>>> >>>>> ... does a

RE: pthread_t and thrd_t

My implementation defines both as pointers, not int's, as 'typedef thrd_t pthread_t;'. Since threads.h is 99% a subset of pthreads.h, I see no reason to have them be different types, even as a breaking change. What is missing is in pthreads.h, to account for the new attributes C11 introduced,

Re: [1003.1(2016)/Issue7+TC2 0001212]: Enhance trap command

The 'trap action sig' form of the command is different from the kernel model, or signal() interface, because all shells have to implement a handler that references the action string and passes it to eval as a special built-in. Whether they use a single function with sigaction(), which has

Re: [1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character

The new wording still doesn't make explicit padding characters for wider field widths than 3 shall be '0', not , to address Bug 1184. What's on the etherpad does have this. Some may argue the minimum field width for "%+" should be 3, as well, as required sign character ('+'/'-') plus 2 digits;

Re: Alias implementations being invalidated by proposed new wording?

Yes, the uses that were discussed are corner cases, but the consensus was, and pretty strongly, not having it would lead to data loss with some operators so the change was added. I don't remember which operators were problematic at this point. This affects built-in aliases more than ones

Re: Alias implementations being invalidated by proposed new wording?

It is possible to ensure an octet represents a graphic of some sort, using uselocale(), isprint(), but this does not do any iconv() type conversion that matches up code point names. So, what's on the screen will still be garbage. It will simply be garbage with glyphs you're used to seeing, not

Re: Alias implementations being invalidated by proposed new wording?

of the token is quoted or not.I believe the expectation is "/bin/util" or "./util", after quote removal, is exempt as specifying a disk access, not a substitution checking util as an alias name. On Tuesday, January 1, 2019 Chet Ramey wrote: On 1/1/19 9:22 PM, Shware Systems wrot

Re: Alias implementations being invalidated by proposed new wording?

Function names are expected to be recognized as such in step 1.c. of XCU 2.9.1.1, that aren't names of standard utilities implemented as functions. As the precondition for getting there is a non-empty command name token is current, it appears the conforming behavior is alias names are checked

Re: Where can I find information on "binding to system-assigned port"

>From the 2018-01-04 conference call, re Bug 1068: "We agree with the concept of using port 0 to get an ephemeral port may be done in a robust, portable, manner, but do not believe that it is appropriate for the Austin Group to define this behavior.  This should be done by IETF/IANA and after

RE: exit status of ! break (in sh)

By XCU 2.9.2 Exit Status, the ! is right associative and all shells should return 1 for "! break" in any context that permits a pipeline; even if the pipe only has one element and no "|" involved. I don't see that there's any ambiguity; while special, break is still considered a command, not a

Re: line continuation (was: sed -e 'a\' -e text)

ise quoted part or not. Maybe it should read "If a follows a ," instead of "... the ,"; but I'm not trying to spread misinformation - it's how I remember the discussion going. In a message dated 8/7/2018 12:50:36 PM Eastern Standard Time, g...@opengroup.org writes:   Shwar

RE: line continuation (was: sed -e 'a\' -e text)

a single quoted portion of a token. That's my take on it, at least, from the discussions we had on when an io_here block starts. On Tuesday, August 7, 2018 Geoff Clare wrote: Shware Systems wrote, on 07 Aug 2018: > > That is a bug in those shells, conformance wise. No buts. Considerat

RE: sed -e 'a\' -e text

In the second example the shell should eat the '\' as part of line joining, so script is abar, not a\bar as the first example should do. That you don't see fooabar as output looks like a bug in your shell, not sed, to me. On Monday, August 6, 2018 Stephane Chazelas wrote: >From the spec at

Re: What does it mean to be "local to the caller of getopts"

It means "the initially unexported shell variables set up by the shell session invoking getopts, either from a script or interactively". This is indicated in 93403: Each time it is invoked, the getopts utility shall place the value of the next option in the shell variable specified by the name

Re: perror() changes the orientation of stderr to byte-oriented mode if stderr is not oriented yet.

The stderr stream is a FILE *, not a file descriptor. While a FILE record can make use of a descriptor, the C standard considers descriptors an extension, not a requirement. So, it's arguable the historical implementation will not compile or execute when __STDC_HOSTED__ is defined on a platform

Re: perror() changes the orientation of stderr to byte-oriented mode if stderr is not oriented yet.

IMO, POSIX is not in need of change until the C standard gets changed. The relevant text in the C standard is copied unchanged from c89, which had no wide characters. Thus text stream by itself, in that context, requires a byte orientation, assuming backwards compatibility is intended to be

Re: can [[:digit:]] match something other than 0123456789?

For conforming charsets XBD 6 requires the range <0>-<9> to be contiguous. By XBD 9.3.5, Rule 6, {:digit:] may include MBS elements aside from the <0> to <9> in LC_CTYPE, but the range [0-9] depends on whether additional characters have the same collation weight as digits. If this is the case

Re: can [[:digit:]] match something other than 0123456789?

at [:digit:] could be written to automatically take into account. In a message dated 5/15/2018 7:29:49 PM Eastern Standard Time, k...@munnari.oz.au writes:   Date: Tue, 15 May 2018 18:42:29 -0400 From: Shware Systems <shwares...@aol.com> Message-ID: <16365f81e7e-179a-29...@webjas-vab

Re: can [[:digit:]] match something other than 0123456789?

That locale would define a latindigs charclass, same as Venusians are required to define a vdigits for theirs, and it's up to the application to do the equivalences to 1, 5, 10, 50, etc. in a latinstr2ull() routine. In a message dated 5/15/2018 6:31:31 PM Eastern Standard Time,

Re: what is [:blank:] *meant* to match (Was: about [:digit:])

To me the distinction stems from which characters are considered information separators (isblank) and which are format effectors (isspace), as control character subtypes, as these pertain only to parsing and printing C source file tokens before and after the preprocessing phase has completed.

Re: can [[:digit:]] match something other than 0123456789?

For that hypothetical Venusian locale, as discussed for 1078, it would be expected to define a VDIGIT (sic) custom LC_CTYPE charclass for specifying other character names representing digits, and then using [[:digit:][:VDIGIT:]] to test for both. Code like this couldn't be considered strictly

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

Apparently, some are reading that as since the \55 is not encoded directly as a the user's intent was to treat it as a literal (or any character specified this way), not ERE operator, as another means of specifying '\-' in this case. An implementation that doesn't use regcomp may only permit

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

For my analysis, 2.6.5 says it is results which are subject to field splitting, with the parameter expand and direct entry both being one field as the pattern to evaluate according to 2.6.6, and the treatment of the double quotes follows from 2.13.1 before removal by 2.6.7 processing. 2.13.1

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

For my analysis, 2.6.5 says it is results which are subject to field splitting, with the parameter expand and direct entry both being one field as the pattern to evaluate according to 2.6.6, and the treatment of the double quotes follows from 2.13.1 before removal by 2.6.7 processing. 2.13.1

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

According to XCU 2.6.5, it's treated literally only when double quoted, e.g. "$var", otherwise quote removal should still occur on the variable's contents after any field splitting... On Friday, April 27, 2018 Joerg Schilling wrote: Robert Elz

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Assuming set +f in effect, the first 2 should expand identically, how I read XCU 2.6.5 and 2.6.6; treating the * as a glob special character and the ? as a literal. For the 3rd case the standard is silent on whether the closing " is assumed on reaching the end of the field established during

Re: [1003.1(2008)/Issue 7 0000655]: Mark strerror_r obsolescent for next issue

lications to call to function reliably.     In a message dated 4/26/2018 2:34:18 PM Eastern Standard Time, dal...@libc.org writes:   On Thu, Apr 26, 2018 at 02:17:38PM -0400, Shware Systems wrote: > It is simple enough to add: > locale_t errlocale=newlocale(LC_MESSAGES, setlocale(LC_MESSAG

Re: [1003.1(2008)/Issue 7 0000655]: Mark strerror_r obsolescent for next issue

It is simple enough to add: locale_t errlocale=newlocale(LC_MESSAGES, setlocale(LC_MESSAGES, ""), 0); to a main() procedure of existing code to get the base handle that thread (or started threads can use as base instead of 0 if a specific locale handle isn't passed in otherwise somehow) for use

RE: was OS X version 10.7 Lion UNIX 03 certified?

I suspect that claim stems from prior versions being certified carrying over if no significant changes to those aspects of the implementation have occurred. They'd have to recertify, I believe, to claim 2008 or 2017 conformance. On Monday, March 12, 2018 Stephane Chazelas

Re: Re: futimens

The act of using TIME_MAX or TIME_MIN as a replacement value is not rounding down, or up for a negative time_t, a provided value to a value representable by the file system, it is what I called pegging, and is different from where the provided value represents a valid time between the

Re: The Purpose and Meaning of IPPROTO_ Constants.

Down-level protocols of TCP and UDP, on IPv4 and IPv6, are considered out-of-scope afaik. Many in common use now weren't implemented to even consider adding to the standard when Issue 6 was started, such as the IPv6 extensions in that database. As IPv4 doesn't support these anyways adding them

Re: Minutes of the 11th January 2018 Teleconference

Group > Andrew Josey, The Open Group > David Clissold, IBM > Andreas Grapentin, University of Potsdam, HPI > Eric Blake, Red Hat > Martin Rehak, Oracle, The Open Group OR > Mark Ziegast, SHware Systems Dev. Co. > Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR > > > * Gen

Re: Re: Handling of a64l()/l64a() when long > 32 bits

...@munnari.oz.au writes:   Date: Thu, 14 Dec 2017 15:57:49 -0500 From: Shware Systems <shwares...@aol.com> Message-ID: <16056d1a8d5-171b-a...@webjas-vaa080.srv.aolmail.net> | The reason I see why arbitrary negative values force the behavior to be | unspecified [...] That isn't what I wa

Re: Handling of a64l()/l64a() when long > 32 bits

The reason I see why arbitrary negative values force the behavior to be unspecified is that masking it to 32-bits may cause an unintended sign reversal. This can occur with positive quantities too, actually. When the upper bits are all ones or zeros, 31 to 63, such flipping doesn't occur so

Re: Re: UTF-8 locale & POSIX text model

It's my understanding that column was added to provide the stock names for those code points in creating charmap files in the format supported by localedef. This is an informative reference for convenience as the standard  also lists those names elsewhere.   As to Q2, the general direction I see

Re: complex.h functions and errno

  When POSIX says "No errors are defined" for a C standard header, that defers to the C standard doesn't require errno be set to specific values, but a POSIX implementation can still elect to set errno due to the 7.3.2 clause. Places where POSIX overrides the C standard get the CX or XSI shading,

Re: [History digging] What were the standardization criteria for multi-threading synchronization primitives?

The overall criteria was and still is, in my opinion based on what made it into the standard, what is the minimum necessary for usable embedded systems that actually had been implemented, as lowest common denominator of portability. Theoretical primitives without implementation, or implemented

Re: Re: [1003.1(2016)/Issue7+TC2 0001154]: Add 'rm -v'

It's my understanding the (at least) refers to other device types that may produce human legible output, that would also get expanded output, but which of these types may be supported by a particular platform or implementation is left unspecified. As phrased it is more inclusive than (or

RE: fscanf white space does not include carraige return

I suspect in that list is meant to include both or , possibly according to a platform's or terminal's line ending convention, rather than list the codes separately. I could see an addition to Application Usage that applications may have to take conventions into account when crafting control

RE: Should "exec" run a shell function?

This could be construed, perhaps, as an exec of sh -c "function body". The effect, in intent, I think would be similar to using exec ./script to invoke the shell indirectly, or to utilities implemented as scripts built-in to the shell. On Sunday, July 16, 2017 Martijn Dekker

RE: ambiguous SHELL specification

>From XRAT A.8.3, the value is advisory, and need not be a directly resolvable path by means the standard provides. What constitutes a valid value for a platform should be documented, and I'd see making that a requirement, as to what applies to the utilities it provides that make use of the

Re: rm -rf ./ ../

It supports base POSIX systems aren't non-conforming, if they use how I interpret it. Requiring both if one exists but not the other is XSI, it looks, but my copy of c165.pdf just has the shading, not the XSI margin code. So we could both be right and wrong on this, lol. On Thursday, June 8,

Re: rm -rf ./ ../

Yes, pretty much. I can't say why it's phrased as it is, I didn't write it. I lean towards some implementation was making unnamed dirents if the file system didn't have those as names, perhaps originally for 8" floppies or 9 track tapes, so something intended to preclude that was added in as

Re: fprintf, snprintf, etc., %n and overflow on the return value

or char. Wider is more a corner case expected to be handled with loops. On Monday, May 22, 2017 Vincent Lefevre <vincent-o...@vinc17.net> wrote: On 2017-05-22 19:55:22 -0400, Shware Systems wrote: > I feel strtoi, or atoi, is appropriate because when * is used the > associa

Re: fprintf, snprintf, etc., %n and overflow on the return value

I feel strtoi, or atoi, is appropriate because when * is used the associated argument is of type int, not any integer type or intmax_t, limiting the string representation too if they're to have the same range. Perhaps this should be explicit too somewhere. The C standard has the same ambiguity,

RE: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

It is not built in as a standard feature, ($@ has limitations) but it is plausible to write shell functions that convert the list to CSV format values, and back, as a "shell only" solution. On Monday, May 15, 2017 Steffen Nurpmeso wrote: Hello. I am wondering whether this

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

By process private I mean a method similar to how pax avoids name collisions when unpacking global extended headers as separate files, using the process id as part of the name of a subdirectory under $TMPDIR to hold those extractions as the default template. This convention isn't completely

Re: Siginfo_t question:

, November 14, 2016 Scott Lurndal <sc...@lurndal.org> wrote: On Mon, Nov 14, 2016 at 04:04:04PM -0500, Shware Systems wrote: > Technically, it doesn't > match. The #defines after provide matching labels for symbolic references, so > portable source most likely will compile, bu

RE: Siginfo_t question:

Technically, it doesn't match. The #defines after provide matching labels for symbolic references, so portable source most likely will compile, but using a field not listed for an si_code value (with an intent of temporary storage, perhaps, rather than increase the frame size for automatic

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

s of fifos to a regular file in a cp pipe or for loop, as the portable option for a gather operation. On Monday, November 7, 2016 Martijn Dekker <mart...@inlv.org> wrote: Op 07-11-16 om 03:55 schreef Shware Systems: > To last question, yes, but the effects are supposed to be documented so &

Re: macOS 10.12, broken PTHREAD_CANCEL_DISABLE and UNIX certification

, November 6, 2016 Per Mildner <p...@sics.se> wrote: On 5 Nov 2016, at 10:22, Shware Systems <shwares...@aol.com> wrote: >From the output, I'm wondering about the source of the Illegal instruction: 4 >diagnostic. If SIGILL isn't blocked, it would also exit the process, and I &

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

To last question, yes, but the effects are supposed to be documented so generic guard code that may invoke platform specific pre-ln attempt handling can be written. This is a compromise to disqualifying a system that defines additional file types from being considered conforming at all. In a

RE: macOS 10.12, broken PTHREAD_CANCEL_DISABLE and UNIX certification

>From the output, I'm wondering about the source of the Illegal instruction: 4 >diagnostic. If SIGILL isn't blocked, it would also exit the process, and I >believe run cancel handlers as part of process shutdown, whatever cancelstate >set to. So something about the code is suspect, but it may

Re: "command" behaviour

As worded the expectation I'd have is that the shell is supposed to exit, as an override of XCU 2.8.1. This puts the onus of error checking on all scripts invoking a script that makes use of exec, however, which I don't see as ideal. What is missing in the first sentence of EXIT STATUS, in < >,

RE: in shell standard (including TC2), program is compound_list or linebreak

There are reasons why they're there, even though not referenced elsewhere in the grammar so appear extra. One is a dot fragment is composed of complete_commands, but is not necessarily a program as a utility embodiment in its own right. The implicit list terminator for them is EOF, however, not

Re: [1003.1(2013)/Issue7+TC1 0001066]: Solution proposal to the 2038 problem.

As epoch is defined relative to UTC/GMT, he has a partial point that Jan 1, 1970 00:00 on the International Date Line would need negative 12*3600 seconds to represent it as the "actual time of day" of XBD 4.15, if midnight GMT assigned as (time_t) 0. To keep all values positive would mean

Re: [1003.1(2013)/Issue7+TC1 0001008]: 1. clarify iconv(3) reset usage; 2. truly support Unicode character input

Knowing which statefulness applies to the code set labels an implementation supports is an implementation quality matter, as part of all those labels being implementation-defined, as I read it. On Thursday, August 4, 2016 Steffen Nurpmeso wrote: Good evening.