%m, #614

[Eric S. Raymond]

Gary E. Miller via devel <devel at ntpsec.org>:
> Richard Laager via devel <devel at ntpsec.org> wrote:
> 
> > Hal Murray via devel wrote:
> > > Gary said:
> > > [API for strerror_r()]  
> > >> On Linux, yes.  But not on all distros.  For example, on Android,
> > >> which gpsd supports, strerror_r() always returns an int.  No
> > >> options.   
> > > 
> > > Same on NetBSD and FreeBSD.  
> > 
> > Right, so that seems like an argument to use the XSI interface, not
> > the GNU one. Everyone but Linux glibc uses the XSI interface, and
> > Linux glibc can be configured to present the XSI interface.
> > 
> > "The XSI-compliant version is provided if: (_POSIX_C_SOURCE >=
> > 200112L) && ! _GNU_SOURCE"
> > 
> > So basically, don't set _GNU_SOURCE, and either don't set
> > _POSIX_C_SOURCE at all, or set _POSIX_C_SOURCE to 200112L (or
> > something newer)?
> 
> Then you can not run on older glibc (pre 2.13).  CentOS supported 2.12 as
> recently as 2017.
> 
> > Then make sure the NTPsec code is consistently written with the
> > assumption of the XSI interface, not the GNU one (i.e. fix one of the
> > mismatches in NTPsec, if that hasn't already been done).
> 
> And breaks not too old distros...
> 
> I'll leave that policy decision to someone else.

Sigh...CentOS, problem child as usual.

If we break this compatibility, I have no doubt whatsoever it will come
back around to bite us. For now, we'll take the alternative that disturbs
old code the least.

I like the general direction of going purely XSI, but I think it'll be
another two years or so before we can do it at acceptably low risk.

Code might be in Go at that point, anyway.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190829/d80b9dc1/attachment-0001.bin>