Re: mailx R and r commands (was: Replying to the list)
> | Solaris uses "Reply-To:" to replace just "From:" > | (although it has "R" and "r" the wrong way round!) > > The original BSD "Mail" did it that way, I have no idea when they > swapped cases, that is 'r' was a "small" reply, and "R" a "big" reply... > > But almost everyone uses "big" replies all the time, replying only to > the author is a less common thing to do, and R is harder to type than r, > so I guess somewhere along the way, someone switched them. > This is controlled by the POSIX-standard mailx variable "flipr". It can be set system-wide (/etc/mail.rc) or per-user ($HOME/.mailrc). Some of the history can be found in the POSIX rationale: "The meanings of r and R are reversed between System V mailx and SunOS Mail. Once again, since this volume of POSIX.1-2017 chose the mailx name, it kept the System V default, but allows the SunOS user to achieve the desired results using flipr, an internal variable in System V mailx, although it has not been documented in the SVID." - Mark
Re: C11/C17 fopen() "wx" and "exclusive access"
I believe that the intention of the committee was to match the preexisting glibc behavior (i.e. "x" maps to O_EXCL). Please refer to the original proposal (N1339) and updated proposal (N1358) as well as the published meeting minutes: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1339.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1358.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1375.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1421.pdf As for the word "exclusive" in the description, I assume it is intended to be interpreted in the same manner as the word that O_EXCL abbreviates; i.e. the access is exclusive (not shared) among those that have requested exclusive access in this manner (such as multiple instances of the same program that might have been run simultaneously). - Mark
Re: [1003.1(2016)/Issue7+TC2 0001184]: strftime %C padding character unspecified
On Fri, 22 Feb 2019 at 02:08, Geoff Clare wrote: > Looking again at bug 472, I believe the resolution has a mistake in > the new text in note 886: it has the "minimum field width is not > specified" case talking about leading sign characters, but this would > need a + flag to be specified without a minimum field width, and P2044 > L65529 (2016 edition) says that the behaviour is unspecified if a flag > is specified without a minimum field width. > I believe that it is intended that '-' be included in %C, %Y, and %G for negative years, even without the '+' flag or a field width, although that is perhaps another area that deserves some clarification. I believe that the "if and only if" in the description of the '+' flag does not match existing practice. - Mark
Re: Adding a clockid_t parameter to functions that accept absolute timespecs (was Re: C++ condition_variable and timed_mutex with steady_clock and pthreads)
On Sat, 27 Oct 2018 at 13:14, Mike Crowe wrote: > On Saturday 27 October 2018 at 15:26:07 -0400, Daniel Eischen wrote: > > > > > On Oct 27, 2018, at 12:14 PM, Mike Crowe > wrote: > > > Looking through POSIX Base Specifications Issue 7, I > > > believe that the following other functions lack a way to use > > > CLOCK_MONOTONIC directly (and unlike pthread_cond_timedwait, I can see > no > > > other way to make them do so): > > > > > > sem_timedwait > > > pthread_mutex_timedlock > > > pthread_rwlock_timedrdlock > > > pthread_rwlock_timedwrlock > > > mq_timedreceive > > > mq_timedsend > > > posix_trace_timedgetnext_event > > > > > > (Many other functions that take a struct timespec treat it as a > relative > > > timeout.) Of these, I've also found it necessary to implement a > version of > > > sem_timedwait that used CLOCK_MONOTONIC. > > > > > > I originally named my function pthread_cond_timedwaitonclock since it > > > seemed that running the words together matched what was happening with > > > "timedwait". Others suggested that it should be > > > pthread_cond_timedwait_on_clock. I've tried to apply that style in the > > > function prototypes below. > > > > I think at least the "on_clock" should be "onclock" or just "clock" for > the same reason timedwait is not timed_wait. Perhaps "_cid" for clock_id? > > > > Also, "clock_" is prefixed to nanosleep for similar functionality, > perhaps pthread_clock_cond_timedwait, etc instead of suffixing with > "_clock" or "_onclock"? > > I think that the clock prefix has some benefits. This would mean: > > sem_clock_timedwait > pthread_clock_mutex_timedlock > pthread_clock_rwlock_timedrdlock > pthread_clock_rwlock_timedwrlock > mq_clock_timedreceive > mq_clock_timedsend > posix_clock_trace_timedgetnext_event > pthread_clock_cond_timedwait > > Although, if you consider the prefix to contain multiple words then they > would be: > > sem_clock_timedwait > pthread_mutex_clock_timedlock > pthread_rwlock_clock_timedrdlock > pthread_rwlock_clock_timedwrlock > mq_clock_timedreceive > mq_clock_timedsend > posix_trace_clock_timedgetnext_event > pthread_cond_clock_timedwait > How about just replacing "timed" with "clock"? sem_clockwait pthread_mutex_clocklock pthread_rwlock_clockrdlock pthread_rwlock_clockwrlock mq_clockreceive mq_clocksend posix_trace_clockgetnext_event pthread_cond_clockwait To me these names seem more appropriate, given that these calls wait until the specified clock reaches the specified absolute value. If the clock can be set, or if an implementation were to support using these with, say, CPUTIME clocks, then "timed" does not seem correct since it is not the time taken by the call but rather the behavior of the specified clock that is significant. - Mark
Re: Availability of the 2016 edition of the specification
On 17 October 2016 at 06:34, Andrew Josey wrote: > Dear all > > We have updated the pdf edition. This addresses the shading issue in the > sysconf() manual page, > some minor layout issues, and the character used to represent > has also been changed > from Unicode LEFT SINGLE QUOTATION MARK to ASCII . > Please note that the page and line numbers are unchanged. > > The updated version is available at the login link on the Austin Group > home page for Austin Group members active in the standards development > process. > > $ cksum C165.pdf > 1678593567 13796737 C165.pdf > > regards > Andrew > > It appears that is still represented by U+2018 LEFT SINGLE QUOTATION MARK in the new version. For example on line 1277, 3646, 74727, 74730, 74738, and many others. Additionally, is often represented by U+2019 RIGHT SINGLE QUOTATION MARK (e.g. line 76378, 76389, 76533, 76658, 76661, 88971, 90440, 95836, 111638, 119617, 127964), is often represented by U+2212 MINUS SIGN (e.g. line 1881, 2402, 2567, 2580, 3517, 3594, 6152, 6164, 65520), is represented by U+02C6 MODIFIER LETTER CIRCUMFLEX ACCENT (e.g. line 1509, 3644, 6105, 6163, 6241, 89508), and is represented by U+02DC SMALL TILDE (e.g. line 2765, 3677, 88669, 89505, 89510, 90551, 90552). (Line number lists are incomplete.) This means that code fragments copied from the PDF will often not work. - Mark
