According to 792 the primary referenced implementations were just on the
mailing list, he didn't copy them to the bug. Somebody might be able to search
2013 posts for them. BSD mentioned, so may be one of them.
On Sun, Sep 15, 2024 at 12:29 AM, Niu Danny via austin-group-l at The Open
Grou
Re: the last bitI think that's to account for the case where an implementation
may asynchronously allow an app thread to modify the base priority while
another thread is blocked on it, not that the example sched_setparam() has to
be in the same thread. While just adding it to the tail of the new
Short answer, no. It was erroneously specified as such in the header
because there wasn't an agreed upon symbolic constant for the size and I
believe this notation was the convention before the C standard adopted flexible
arrays. While an implementation should declare a symbolic constant, some
This is for files that do not specify a separate codeset at all, and for
interpreting a file that does specify one before it gets to the line with the
codeset directive, is my understanding, so needs to be there (for now, maybe
not in future). It maybe should be more explicit codeset changes sta
It appears to me the set -b wording needs updating, to clarify "may remove the
job's process ID" is intended to exclude the blocking circumstances listed, and
since it's a "may", not "shall", whether those exclusions are handled properly
now is more a quality of implementation than conformance i
The compliance factor for locales is more of documentation than exclusionary,
so Thorsten is correct, the standard allows what he does. Just the fact
localedef can use any encoding model via suitable charmap data makes this
somewhat obvious. An implementation may provide locales using any charac
Historically, gettext domains are process wide, making use in multi-threaded
apps problematic to begin with. The *_l versions only partially address this.
The uselocale() interface is included there for the cases where a locale is
used by both a uselocale() and one or more of the *_l versions, i
scope of the C standard, I think a lot has been left out so implementations, or
standards like POSIX, aren't locked into having to provide things that their
end users will rarely, if ever, need.
On Fri, Jan 7, 2022 at 1:46 PM, Steffen Nurpmeso wrote:
Hello.
shwa
The first Issue 8 draft is focusing, afaik, on adding the C1x changes and
Mantis Issue 8 tagged items. The changes to XBD 6, 7, etc., that will formally
add a POSIX UTF8 locale are to be part of the second, maybe third, draft. This
is why you don't see them yet.
For maximum compatibility with ex
Yes, there's a path; file an Enhancement Request in Mantis. However, if toybox
wants to be more POSIX conforming it'll have to add an awk implementation
anyways, eventually, so not sure such a request would get much traction for
sponsorship. Those with awk already might not want to add it to the
This is felt required to get POSIX accurately describing what the C standard
version of system() requires, taking into account where sh differs from the
minimal requirements of the command shell in that standard. POSIX is as it is
because it was assumed no programmer would use a option switch ch
To the extent XBD 11.1, #6 applies and 2's complement notation is the internal
representation required, the standard is pretty clear. The first 3 cases all
evaluate to numeric 0, whether specified in paired quotes or not since the
shell does quote removal, the +0 case is always a string since +
That was a typo, it looks, 723 for 713. Correct link is:
https://austingroupbugs.net/view.php?id=713
On Tue, Jun 15, 2021 at 4:45 PM, Fred J. Tydeman via austin-group-l at The
Open Group wrote: On Tue, 15 Jun 2021 18:13:35
+0100 Andrew Josey via austin-group-l at The Open Group wrote:
>
It is covered in Item 7 of those 11 exceptions, 'x' falling under the blanket
"every character not specified is 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 w
, Joerg Schilling via austin-group-l at The
Open Group wrote: "shwaresyst via
austin-group-l at The Open Group" wrote:
> No, it's not nonsense. The definition of comment has all characters,
> including '!', shall be ignored until newline or end-of-file being
here in a script, at the expense of a few extra characters for the here
delimiter and set commands, without any other changes to tokenizing or the
grammar.
On Sun, Apr 11, 2021 at 12:15 PM, Harald van Dijk wrote:
On 11/04/2021 17:09, shwaresyst via austin-group-l at The Open Group w
any of those. There is NO allowance for
'!' being the second character as reserved for implementation extensions.
On Sun, Apr 11, 2021 at 11:37 AM, Robert Elz wrote:
Date: Sun, 11 Apr 2021 10:46:48 +0000 (UTC)
From: shwaresyst
Message-ID: <14131279
That's bugs in those shells for POSIX mode then, that I see. The conforming
behavior is /usr/gcc is found and succeeds at doing nothing, since it contains
just a comment line. Other elements of path never get checked. Even in
non-POSIX mode, trying to process it as a shebang with "/bad" as a ENO
simple check of
VERSION at the top of a source C file suffices now to indicate those constants
shall be available.
On Tuesday, March 9, 2021 Eric Blake wrote:
On 3/9/21 10:14 AM, shwaresyst wrote:
>
> To me that looks like a conformance violation and should be reverted. There
> is no
To me that looks like a conformance violation and should be reverted. There is
no _SC_SIGSTKSZ defined in by the standard, to begin with, so that
use of sysconf() is a non-portable extension on its own.
I could see the definition of SIGSTKSZ being changed to the static minimum a
particular pr
At that point in the grammar TOKEN is "esac)" or "(esac)", from which the WORD
"esac" is extracted, not converted to Esac, as right paren is not an operator
character that terminates token recognition. Rule 4 applies to "esac ;" or
"esac" linebreak, no right paren discovered on lookahead, that
I agree more clarification is desirable. The reason I see as why the function
isn't executed is it may be treating it as an invoke of "sh -c ls", because ls
is a function, but this new sh does not inherit that definition so it looks on
path instead and finds the utility.
On Wednesday, December
e
versions of the standard with one runtime and set of headers.
On Thursday, December 3, 2020 Robert Elz wrote:
Date: Thu, 3 Dec 2020 18:11:51 + (UTC)
From: shwaresyst
Message-ID: <684426419.4103424.1607019111...@mail.yahoo.com>
| The 20yymmL shall be replaced wi
The 20yymmL shall be replaced with the value specific to Issue 8 when that is
finalized, not that an implementation may choose an arbitrary value after 2000.
It's a placeholder to indicate this for the bug report only. The other 200809L
values all get a blanket change eventually too, consistent
is specified.
On Tuesday, November 3, 2020 Paul Smith via austin-group-l at The Open Group
wrote:
On Mon, 2020-11-02 at 15:44 +, shwaresyst via austin-group-l at The
Open Group wrote:
> With that phrasing is also reserved, since it
> is not " followed ONLY by uppercase". Using "
With that phrasing is also reserved, since it is not
" followed ONLY by uppercase". Using ".NO_parallel" would be similarly
conforming, it could be argued.
On Monday, November 2, 2020 Geoff Clare via austin-group-l at The Open Group
wrote:
Joerg Schilling wrote, on 31 Oct 2020:
>
> Well this
t 2's comp. internal format as an actual value.
On Saturday, October 24, 2020 Robert Elz wrote:
Date: Sat, 24 Oct 2020 16:47:41 + (UTC)
From: shwaresyst
Message-ID: <160402159.2963847.1603558061...@mail.yahoo.com>
| The text relevant to all this I s
The text relevant to all this I see is the paragraph at line 104150, page 3114,
c181.pdf, which limits outputs to the internal representation range of the
format characters used, converted back to text. This should probably be
explicit that the conversion shall detect overflows, positive or neg
The C standard leaves it undefined for fread() because it doesn't require
EOVERFLOW in , that I see, or presumes size_t will always be a short
or int type. Since POSIX does have it and does not presume a limited width I
feel this is a place where a CX extension is warranted as a portability
co
As I read it, file size and *seek(SEEK_END, 0) will still be 16, reflecting how
many bytes were written to the buffer and which had to be malloc'd. The rewind
overwrites the first bytes and a flush, close reflects the size of data
considered to be valid after the rewind, since there is no guara
It's my understanding ISO/IEC was to bump their distribution also, to keep in
synch. Nick S. would be more conversant with the details of thay, though.
On Monday, September 28, 2020 Jonathan Wakely wrote:
On 28/09/20 14:36 +0000, shwaresyst wrote:
>
>The 2018 edition is the latest I
The 2018 edition is the latest ISO/IEC/IEEE version, in that it was balloted
and approved to keep the IEEE "current standard" clock from timing out. The
2008 edition plus TCs is now the prior version, in the formal sense.
On Thursday, September 24, 2020 Jonathan Wakely via austin-group-l at The
application.
On Tuesday, September 22, 2020 Robert Elz wrote:
Date: Tue, 22 Sep 2020 14:38:07 + (UTC)
From: shwaresyst
Message-ID: <32911555.5186984.1600785487...@mail.yahoo.com>
| Yes, it is no longer a factor,
I would have guessed that is what "not
pointer to the attr object.
On Tuesday, September 22, 2020 Robert Elz wrote:
Date: Tue, 22 Sep 2020 11:05:05 + (UTC)
From: "shwaresyst via austin-group-l at The Open Group"
Message-ID: <1248402378.5117076.1600772705...@mail.yahoo.com>
| Once p
Once pthread_attr_init() successfully completes the guardsize should be set to
the default value and may be examined by pthread_attr_getguardsize(), that I
see. A call to setguardsize() should store the value and be returned by
subsequent getguardsize() calls, even though it is not used after
nd the need to page-align data structures in some
situations, I still don’t see its relevance to a discussion of the C standard’s
requirements regarding padding in struct types and how it’s affected by
flexible arrays.
From: shwaresyst
Sent: September 2, 2020 1:58 PM
To: Wojtek Lerch
n a VLA. A flexible array is not a VLA, in the sense C uses the term.
From: shwaresyst
Sent: September 1, 2020 4:55 PM
To: Wojtek Lerch ; austin-group-l@opengroup.org
Subject: RE: [1003.1(2013)/Issue7+TC1 697]: Adding of a getdirentries()
function
What that refers to, it looks,
hing still needs to be
implemented to be wrapped.
On Tuesday, September 1, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<1739483391.1543785.1598977118...@mail.yahoo.com>:
|No, it couldn't introduce such a macro, because such would have to \
|assume all d_name entries are the s
. Furthermore,
requiring these existing implementations to change their layout would break
binary backwards compatibility with previous versions.
See DR282 for more
details:http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_282.htm
From: shwaresyst
Sent: September 1, 2020 2:27 PM
I agree some additional clarity might be useful there, in the C standard. I'm
reading it as the intent being sizeof is equivalent to offsetof the VLA in
accordance with the restrictions placed on it by use of the . or -> operators,
which may not need extra bytes (so &s->vla == (&s + sizeof(s))
No, it couldn't introduce such a macro, because such would have to assume all
d_name entries are the same length. Adding an option to the interface to do a
count, as a vararg parameter, and directly malloc the necessary space, returned
via my suggested change to buf as a **, is plausible. Since
It's my understanding, by C11 6.7.2.1p18, sizeof on a struct with a variable
array works as if the variable member was not present, but does count any bytes
added for alignment padding, as this will be a fixed amount for each use of the
struct. It is up to the application, like with variable ar
e Open Group
wrote:
shwaresyst wrote, on 05 Aug 2020:
>
> On Wednesday, August 5, 2020 Geoff Clare via austin-group-l at The Open Group
> wrote:
>
>> My own thoughts up to now had been that, since the slave side is the
>> side that is intended to be used as a terminal in the n
The slave side is ancillary to the master, sorry, as physical terminals are
ancillary to the processor hardware, imo. Inverting the relationship makes it
look like it is the intent of the slave side to source the majority of the
data, when more often it is only monitoring output data sourced by
Robert has a point that assignments, as represented by the ASSIGNMENT_WORD
token in the grammar, should be represented by a production of the form:
ASSIGNMENT_WORD :: name EQ WORD
For 2.6.1 that is the assignment form referenced where word expansion, of the
WORD in that production, is relevant
uence conversions are
plausible, it's just how has no portable specification currently, it is left as
unspecified.
On Friday, July 31, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<1371185781.9853799.1596158030...@mail.yahoo.com>:
|It is not "some sensible \u sequences" alone.
ere are interfaces
for the utilities to be written in that understand left-associative combining
sequences, and these interfaces are portable because requirements in XBD add
that support.
On Thursday, July 30, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<1127836834.9524758.1596121054.
to
be written, or published if some have been.
On Thursday, July 30, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<311169368.9432836.1596108598...@mail.yahoo.com>:
|On Thursday, July 30, 2020 Geoff Clare wrote:
|Robert Elz wrote, on 29 Jul 2020:
|>
|> Speaking of which,
Also, as something new, its inclusion is part of a later draft of Issue 8.
Additional issues it depends on need to be addressed first, specified fully,
and incorporated. This is more why it went on the back burner, that I recall.
Various other bugs are in similar state; the prerequisites to fin
That the semantics are unspecified already disqualifies them from use by
portable applications. If it was implementation-defined then such an addition
might be warranted, that I see.
On Saturday, July 25, 2020 Danny Niu wrote:
RFC 6093 "On the Implementation of the TCP Urgent Mechanism"
surveys
C", and by extension "POSIX",
locale is unchanged from C99, and has not added %Z. This would apply to its
usage both by strftime() and strptime(), to maintain symmetry, I would think.
On Tuesday, July 21, 2020 J William Piggott wrote:
On Sun, 12 Jul 2020, shwaresyst wrote:
Thank
That reference was left as-is because the Issue 8 draft targets C17 (or 18),
but there's a chance c2x may get ratified first so that may affect later drafts.
On Sunday, July 19, 2020 Quentin Rameau wrote:
Hello,
> ==
> Summary
The reason for the disconnect, that I see, is because the %Z modifier
references the TZ environment variable, not a value in a struct tm, adding it
to d_t_fmt would disqualify the definition from being __STD_C__ conforming.
This is one of the areas where the C standard can be considered broken,
That still has some_other_command never getting executed, so I think just
adding the printf sufficient.
On Wednesday, July 8, 2020 Nick Stoughton wrote:
The whole point of this example is to show that the exit status *of the while
loop* will be zero if the loop does not execute, and if you care
.yiv9332244889MsoChpDefault {font-family:sans-serif;} _filtered
{}#yiv9332244889 div.yiv9332244889WordSection1 {}#yiv9332244889
Yes, but the same logic (0 being unambiguous in all radices) equally applies to
1.
From: shwaresyst
Sent: Monday, July 6, 2020 18:35
To: Schwarz, Konrad (CT RDA IOT SES
The necessity for "0x" is to disambiguate from octal numbers with their leading
'0', or decimal for a context allowing leading zeroes, but since a 0 is the
same in all radices I suspect the decision was not to require it to keep field
width minimal for delimited formats like CSV.
As to 2nd, "
There are plans for this, having a POSIX.UTF-8 locale as an XSI base
requirement. There may be POSIX.UTF-E and UTF-I locales too; same features,
simply the different charmaps. As options there may even be, albeit this is
unlikely as no platform I'm aware of fully supports ISO-6429 now, a POSIX.
The locale requirements specified in the C standard are what is applicable for
implementations that limit their character encoding to the basic source and
execution character sets. POSIX requires implementations to support, in at
least one provided charmap, the superset of the basic sets repres
Re: Are not the examples demonstrating relevant date utility specification
requirments as follows:
No, they are examples of how the various specified elements can produce output
reflecting various locale LC_TIME settings, that's all. The actual format
string is still an unspecified implementati
The command alias is nominally conforming, I believe, in that recursive alias
expansion isn't permitted so looking for a utility named command still occurs.
However, the implementation of various utilities as aliases changes the
reporting of 'command -v', or '-V', to that they are aliases and
There is also the POSIX locale is a superset of the C locale as defined by the
C standard, because it requires support of the Portable Character Set, which
has more chars than C requires, and has the LC_MESSAGES category; as primary
differences.
On Wednesday, June 10, 2020 Joerg Schilling
wro
No, I did have the "respectively" in there, for 3 separate possible file
descriptions. It is also, near as I can tell, a requirement of the C standard
those FILE records exist and be usable at program startup, whether
included or not, for referencing either an already open stream or be in a
c
equire this.
On Friday, May 29, 2020 Robert Elz wrote:
Date: Fri, 29 May 2020 14:59:48 + (UTC)
From: shwaresyst
Message-ID: <58121613.1659567.1590764388...@mail.yahoo.com>
| Isn't there something about stdin, stdout, and stderr being required to
| re
Re: matter in connection with
C's stderr but only for file descriptor 2 (as inherited by the login
shell).
Isn't there something about stdin, stdout, and stderr being required to
reference the same open file descriptions as fd's 0, 1, and 2, respectively,
with inheritance? An application can c
Personally, the offer is appreciated, but I would not find scans of the
documents wrapped as a pdf all that useful, if this is intent. Using the
original troff, if this is still available, to generate copy and searchable
versions, with TOC and xrefs, would be nicer.
On Monday, May 18, 2020 J Wi
Just floating this out there... While a posix_spawnp() kernel imp doing PATH
searches relative to the parent's pwd is a well defined behavior, should there
be an additional file_action that search for the executable happens after the
chdir action; for the case where PATH, as inherited by the chi
aturday, May 9, 2020 Robert Elz wrote:
Date: Sat, 9 May 2020 13:00:54 + (UTC)
From: shwaresyst
Message-ID: <600759678.614717.1589029254...@mail.yahoo.com>
| Just floating this out there... While a posix_spawnp() kernel imp doing
| PATH searches relative to
indicate end of pattern, not ')', but these don't become part of the base PCS
until Issue 9.
On Wednesday, April 22, 2020 Joerg Schilling
wrote:
shwaresyst wrote:
> No, you only lex up to the newline or EOF in the first pass, whether the
> ending ')' or other co
mmand in addition to cmd-name that specified alias names were to be
checked for first lexically, then you'd have a stronger case, but it never has
that I've seen.
On Wednesday, April 22, 2020 Joerg Schilling
wrote:
shwaresyst wrote:
> When you are evaluating substitutions, yes, ex
trying to claim it is impossible to have an interpreter that expands
alias bodies first, simply that sh does not do it that way due to the possible
ambiguities.
On Tuesday, April 21, 2020 Joerg Schilling
wrote:
shwaresyst wrote:
> No, those are attempts at speed optimizations; the descript
bert Elz wrote:
Date: Mon, 20 Apr 2020 21:17:12 +0000 (UTC)
From: shwaresyst
Message-ID: <1050536090.3716059.1587417432...@mail.yahoo.com>
| No, those are attempts at speed optimizations;
I'm sad to have to reply like this, but do you have any idea at all
holds an actual name until recognition of the line as a whole has been
completed.
On Monday, April 20, 2020 Robert Elz wrote:
Date: Mon, 20 Apr 2020 18:01:49 + (UTC)
From: shwaresyst
Message-ID: <1837359500.1041757.1587405709...@mail.yahoo.com>
| It seems
It seems to me that what is missing, in XCU 2.3.1, is a statement that use of
keywords in alias bodies is unspecified behavior.
Even outside double quotes an initial scan collecting tokens to form a logical
line distinct from a potential io-here body will have to treat an alias name as
a comm
yes, it is being worked on but not as a high priority, so Option 2 appears to
be a no go. It may be better to revisit the bug and add a test for its
availability to sysconf()/getconf as a formal option, in a Coming Attractions
sense, so code can be written portably now based on using Option 1 o
ce.
On Thursday, April 2, 2020 Geoff Clare wrote:
shwaresyst wrote, on 02 Apr 2020:
>
> This is not a duplicate, bug 315 covers only one case, this points out it
> applies to other places. If anything it is a child, not duplicate, that's why
> it was Accepted.
It was not
This is not a duplicate, bug 315 covers only one case, this points out it
applies to other places. If anything it is a child, not duplicate, that's why
it was Accepted.
On Thursday, April 2, 2020 Austin Group Bug Tracker
wrote:
The following issue has been set as DUPLICATE OF issue 315.
Um, I did not say that people should get a draft whenever they want one, simply
that the other list is being underutilized for discussion of issues arising
from Mantis, not any drafts, until we have a release we feel is ready for
public review. I wholly agree trying to reference non-releases wo
This has been suggested, but the ORs feel the time for such is when Issue 8 is
formally released, not before. The austin-futures-l list is more the intended
vehicle for issues of that nature, as to what's in place already, but it does
not have its own Mantis, or other browser based, interface.
it likely was.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 23:30, shwaresyst wrote:
> yes, without them the argument would be "nnnd", after quote removal by
> the shell. The reasoning in first reply was meant to show that the
> non-GNU versions might be er
se as delimeter overrides that interpretation, to
get the results observed.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 21:09, shwaresyst wrote:
> If it wasn't in single quotes, then that might be plausible, but I don't
> see it as the intent since no other alia
se as delimeter overrides that interpretation, to
get the results observed.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 21:09, shwaresyst wrote:
> If it wasn't in single quotes, then that might be plausible, but I don't
> see it as the intent since no other alia
terminator, and the following 'n' is the terminator, before the
'd' command. Should there be something explicit about aliases not being usable
when repurposed as delimiter, maybe.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 19:44, shwaresyst wrote:
> The GNU
The GNU version is more correct, in my opinion, in that the use of n as a
delimiter should take precedence over its use as control character alias with
the wording as is. The other versions appear to consider the BRE as
so does not match 'n'.
On Wednesday, March 25, 2020 Oğuz wrote:
echo
I can't reopen the bug to add a note, so like we did 1318 on top of 411, it
probably should be reopened and discussed. Straightforward or not, what you put
in is not what is marked as to be put in.
On Thursday, March 19, 2020 Geoff Clare wrote:
shwaresyst wrote, on 18 Mar
Note 1190 does not include mention of -include, so imo a separate note should
be added showing what was committed. As example, the text about "file not
found" always invoking unspecified behavior is not true for -include, it is now
explicit these are ignored as the specified behavior.
On Wednes
The wording can be construed the intent is the EXIT trap is always expected to
be called, with a SIGEXIT delivered to the context of the subshell and not the
parent, and otherwise to the parent for performing the trap in its context and
terminating the parent. While a subshell context is create
For the example provided I think you are right it is a potential issue in that
the shell only specifies that commands will be in a separate execution
environment, without being explicit the requirement of fork() to keep process
IDs unique applies to these environments. It just has that the envi
Yw... Also, while change is minor, just putting out for next meeting, we
probably want to take a look at the Related: bugs with Interpretations, see if
any those need a timer restart to reflect the change properly.
On Thursday, March 12, 2020 Eric Blake wrote:
On 3/12/20 1:02 PM, shwaresyst
Fyi, the Last updated: date at top wasn't changed.
On Thursday, March 12, 2020 Austin Group Bug Tracker
wrote:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=411
I agree this is something suitable for a TC type resolution. However, given the
amount of existing practice, I do not see we should leave anything unspecified
for Issue 8, even if some implementations break as a result.
Either it always stops function execution or dot file processing, which ca
ase.
On Tuesday, March 10, 2020 Dirk Fieldhouse wrote:
On 10/03/20 18:25, shwaresyst wrote:
>
> I basically agree this is an issue - I see return as more for being
interpreted as a lexical scope abort, whatever the execution context,
and exit an execution scope abort, such as a subshell or s
I basically agree this is an issue - I see return as more for being interpreted
as a lexical scope abort, whatever the execution context, and exit an execution
scope abort, such as a subshell or separate script utility environment, as
their basic intent. Further complicating things, I don't see
backwards
compatibility or needing any new keywords.
On Tuesday, February 25, 2020 Robert Elz wrote:
Date: Tue, 25 Feb 2020 17:47:23 + (UTC)
From: shwaresyst
Message-ID: <1701159045.321204.1582652843...@mail.yahoo.com>
| The thing is, various shells have imp
The thing is, various shells have implemented time as keyword, so this bug is
trying to get the standard to reflect actual practice that ignored that
Rationale. The debate is more some things allowed to utilities aren't allowed
for keywords, and vice versa, so there are advantages to both.
As
I disagree with the notion of using names with colons, especially for new
utilities, mainly because colon is the character used as path separator in PATH
and there may be usage ambiguities resulting from this overload. I'd be more in
favor of implementing labels with another character entirely
If you're going to go with 'z' suffix, "statz" is an option too; for
session/process statistics or "state of the machine".
On Monday, February 24, 2020 Scott Lurndal wrote:
On Mon, Feb 24, 2020 at 09:23:16AM +, Geoff Clare wrote:
> Chet Ramey wrote, on 16 Feb 2020:
> >
> > On 2/15/20 9:42 P
The parentheses are there to indicate all those are interfaces, without the
wordier "last msgsnd interface call", or similar, in those lines.
On Sunday, February 23, 2020 Austin Group Bug Tracker
wrote:
The following issue has been SUBMITTED.
==
7;t require this so silently storing the definition, and
confusing the user, are more the conforming behavior.
-Original Message-----
From: Joerg Schilling
To: shwaresyst ; kre
Cc: gwc ; austin-group-l
Sent: Tue, Feb 18, 2020 12:08 PM
Subject: Re: Re: [1003.1(2004)/Issue 6 267]: time (k
riginal Message-
From: Robert Elz
To: shwaresyst
Cc: Joerg.Schilling ; gwc
; austin-group-l
Sent: Tue, Feb 18, 2020 11:34 AM
Subject: Re: [1003.1(2004)/Issue 6 267]: time (keyword)
Date:Tue, 18 Feb 2020 15:26:43 + (UTC) From:
shwaresyst
It shouldn't matter whether a token prefix matches a reserved word or not;
because the lparen is not separated by a function definition should be
the "best, longest" match production that it is interpreted as, and so wouldn't
be a syntax error. It's on use that keyword recognition would hide w
1 - 100 of 149 matches
Mail list logo
