Re: using printf for ssize_t values

On Tue, 10 Jan 2017, Eric Blake wrote: > C99 does NOT require ssize_t. ssize_t is a POSIX invention, Although awkwardly the C TR 24731-2 defines interfaces that use ssize_t, without including any specification of that type and without specifying any header that should define it when __STDC_WA

Re: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

On Thu, 8 Jun 2017, Andrew Josey wrote: > We’re not able to make available IEEE copyrighted materials that > pre-date the MoU of 1998, hence although many of us as individuals have > older POSIX drafts obtained as part of the standards development process > at the time, we cannot post them . W

Re: Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

On Thu, 8 Jun 2017, Stephane Chazelas wrote: > 2017-06-08 15:28:49 +0100, Geoff Clare: > > Stephane Chazelas wrote, on 08 Jun 2017: > > > > > > BTW, are older (than SUSv1) versions of POSIX available > > > somewhere? > > > > All previous versions were only distributed on paper. > > OK. Does any

RE: Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

On Thu, 8 Jun 2017, Joe Gwinn wrote: > Joseph M, > > What will you do with this old standard? I routinely use these standards for reference for implementation work (since in practice implementations deal with multiple standard versions, not just the latest), as well as for understanding the hi

Re: Differences between versions of the standard

On Mon, 12 Jun 2017, shwares...@aol.com wrote: > This would be the XRAT volume, and Change History in individual entries... > This is only exhaustive in coverage from when the POSIX Group was formed, > it appears, not for earlier IEEE and OpenGroup versions. There is a table XPG5, PDF versi

Re: complex.h functions and errno

On Wed, 8 Nov 2017, Bruce Evans wrote: > This is without Annex F (IEEE754/IOCmumble bindings). With Annex F, > cabs() is specified in terms of hypot() and atan2(), so math_errhandling > accidentally applies to it (via the hypot() part). However, overflow is I think that specification is only fo

Re: complex.h functions and errno

On Wed, 8 Nov 2017, Don Cragun wrote: > Hi Hal, > I agree with what others have already said in this thread, but I think > there is a more basic issue at play here. In the example you provided: > cabs(1.7e308+I*1.7e308); > the multiplication is not being performed by the function. It is

Re: complex.h functions and errno

On Fri, 10 Nov 2017, Bruce Evans wrote: > Hmm, POSIX has the caveat that functions might never see signaling NaNs > since parameter passing might turn them into quiet NaNs (and raise an > exception). I'm used to i387 floating point where this tends to always So indeed does TS 18661-1 (assignment

Re: complex.h functions and errno

On Thu, 9 Nov 2017, Hal Finkel wrote: > Thus, neither cabs, nor most other math.h/complex.h functions taking > floating-point inputs and producing a floating-point output, should ever > formally overflow (because even infinity lies within the represented set), and > so shouldn't set ERANGE (regard

Re: UTF-8 locale & POSIX text model

On Sat, 25 Nov 2017, k...@keldix.com wrote: > systems, and also implementations that can conform using UTF-16 and > different 8-bit codesets. For instance 'A' is coded x0041 (two bytes) in > UTF-16 > and x41 (only one byte) in cp850, and UTF-8. ISO C includes (C99 TC2 onwards) the requirement "

Re: About issue 0001108 and abs(INT_MIN)

On Mon, 16 Jul 2018, Vincent Lefevre wrote: > As expected, the text in http://austingroupbugs.net/view.php?id=1108 > makes Debian's c99 utility behave incorrectly. FYI, I've reported a > bug: While I think the changes proposed for issue8 are wrong, they clearly can't result in a bug in any c99 u

Re: [1003.1(2016)/Issue7+TC2 0001108]: LONG_MIN must be <= -2147483648

On Wed, 11 Jul 2018, Vincent Lefevre wrote: > I completely disagree on this change. Undefined behavior is useful Likewise. That part of the changes is clearly a bad idea and should not be applied to issue 8. -- Joseph S. Myers jos...@codesourcery.com

Re: About issue 0001108 and abs(INT_MIN)

On Thu, 19 Jul 2018, Joerg Schilling wrote: > Signed integer overflow can only trigger undefined behavior in case that more > than a single specific architecture could be envolved. No, signed integer overflow is part of the contract between a C programmer and the implementation. A C programmer

Re: About issue 0001108 and abs(INT_MIN)

On Thu, 19 Jul 2018, Joerg Schilling wrote: > Since the C++ people already think about making this to happen in ther next > standard, it seems that the C compilers may do something similar in the > future. The latest version of the C++ proposal

Re: About issue 0001108 and abs(INT_MIN)

On Thu, 19 Jul 2018, Davin McCall wrote: > So, this POSIX requirement doesn't actually impose any extra requirements on > the C compiler, if I understand correctly - just on the implementation of the > abs() functions. In practice (and again for 20 years or more), compilers do not generate out-o

Re: sh: aliases in command substitutions

On Mon, 20 Apr 2020, Robert Elz wrote: > then XCU 2.2.3 (2.2 is "Quoting" 2.2.3 is "Double-Quotes") > (lines 74718-22, Issue 7 TC2 - 2018 edition) says ... > > The input characters within the quoted string that are also enclosed > between "$(" and the matching ')' shall not be affected b

Re: sh: aliases in command substitutions

On Tue, 21 Apr 2020, Robert Elz wrote: > Probably not, it was an interpretation of the 1992 standard, and so > was probably not earlier than 1993 (I see some 1996 copyrights, but wjether > that's for the specific interpretation or just the collection I don't know). I received that interpretation

RE: [Issue 8 drafts 0001349]: Where to obtain ISO/IEC standards (footnote)

On Mon, 20 Jul 2020, Schwarz, Konrad wrote: > Hmm, I distinctly remember you used to be able to get old versions of > standards from ISO - but I can't find how to do so on the current > version of the ISO web site either. To quote https://www.iso.org/shopping-faqs.html "Withdrawn standards can

Re: tv_nsec

On Fri, 20 Jan 2023, Geoff Clare via austin-group-l at The Open Group wrote: > Nick Stoughton wrote, on 19 Jan 2023: > > > > 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