Richard Laager via devel writes:
> I haven't fact checked you, but what you're saying about the APIs sounds
> reasonable. Is there any chance you could propose a patch to fix this?
> (Or have you already and I missed it?)
There is no single right solution to this, but there are several completely
How about this:
https://gitlab.com/NTPsec/ntpsec/merge_requests/1027
I'd love to know if that builds and works on all the supported
platforms. It seems like it should.
If there are problems with the approach from the first commit, the
second (renaming mystrerror to ntp_strerror_r) and third (usin
Gary E. Miller via devel :
> Richard Laager via devel 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
> > >> option
Yo Richard!
On Thu, 29 Aug 2019 16:52:16 -0500
Richard Laager via devel wrote:
> On 8/29/19 4:04 PM, 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 return
On 8/29/19 4:04 PM, 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 argumen
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.
The quirk that's not in the man page is that the GNU version doesn't use the
buffer you pro
Yo Richard!
On Thu, 29 Aug 2019 14:35:36 -0500
Richard Laager via devel wrote:
> On 8/29/19 2:20 PM, Gary E. Miller via devel wrote:
> > Sadly we do not get to pick the API. The user picks the available
> > APIs when he picks a distro.
> Read `man strerror_r`. The defines determine which API
On 8/29/19 2:20 PM, Gary E. Miller via devel wrote:
> Sadly we do not get to pick the API. The user picks the available
> APIs when he picks a distro.
Read `man strerror_r`. The defines determine which API (XSI or GNU)
glibc provides. You, the application author, pick the API by setting the
macros
Yo Achim!
On Thu, 29 Aug 2019 21:09:10 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> --8<---cut here---start->8---
> >> _GNU_SOURCE should not always be defined, but it does need to be
> >> defined in certain cases. For example, o
Achim,
I haven't fact checked you, but what you're saying about the APIs sounds
reasonable. Is there any chance you could propose a patch to fix this?
(Or have you already and I missed it?)
--
Richard
___
devel mailing list
devel@ntpsec.org
http://list
Gary E. Miller via devel writes:
>> --8<---cut here---start->8---
>> _GNU_SOURCE should not always be defined, but it does need to be
>> defined in certain cases. For example, on glibc < 2.10, you need to
>> define it to get strnlen() and struct ifreq.
>>
>> Fr
Yo Achim!
On Thu, 29 Aug 2019 07:53:23 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> But this thread is about that exact function.
> >
> > We'll have to disagree there. I feel it is much more generic to
> > the defines that pull in stuff.
>
> THen change the su
Gary E. Miller via devel writes:
>> But this thread is about that exact function.
>
> We'll have to disagree there. I feel it is much more generic to
> the defines that pull in stuff.
THen change the subject or open your own thread, please.
>> > Not at all what I meant. Flexible about what NTPs
Yo Achim!
On Wed, 28 Aug 2019 22:17:43 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > I was not talking about strerror_r().
>
> But this thread is about that exact function.
We'll have to disagree there. I feel it is much more generic to
the defines that pull in s
Gary E. Miller via devel writes:
> I was not talking about strerror_r().
But this thread is about that exact function.
> I was talking about strnXXX()
> and struct ifreq.
If you talk about strnlen, it's not used in ntpsec (current master).
The other strnXXX functions are ANSI C and don't need a
Yo Achim!
On Tue, 27 Aug 2019 22:54:43 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> In that case, you need to be prepared for changed semantics in
> >> several places and I don't think ntpsec is set up to deal with
> >> that.
> >
> > Changed semantics? No. Simpl
Gary E. Miller via devel writes:
>> In that case, you need to be prepared for changed semantics in several
>> places and I don't think ntpsec is set up to deal with that.
>
> Changed semantics? No. Simple existence of the prototpe is at stake.
Go back to the original thread and/or read the manua
Yo Achim!
On Tue, 27 Aug 2019 19:42:30 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > _GNU_SOURCE should not always be defined, but it does need to be
> > defined in certain cases. For example, on glibc < 2.10, you need
> > to define it to get strnlen() and struct ifr
Gary E. Miller via devel writes:
> _GNU_SOURCE should not always be defined, but it does need to be defined
> in certain cases. For example, on glibc < 2.10, you need to define
> it to get strnlen() and struct ifreq.
In that case, you need to be prepared for changed semantics in several
places an
On Mon, Aug 26, 2019 at 04:55:48PM -0700, Gary E. Miller via devel wrote:
> _GNU_SOURCE should not always be defined, but it does need to be defined
> in certain cases. For example, on glibc < 2.10, you need to define
> it to get strnlen() and struct ifreq.
>
> From glibc 2.10, you instead need _
Yo Achim!
On Mon, 26 Aug 2019 21:00:18 +0200
Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > waf turns on _GNU_SOURCE
>
> There's your bug. You can't do that if you want to stay portable,
> thus you must find another feature test macro for whatever feature
> you are looking f
Hal Murray via devel writes:
> waf turns on _GNU_SOURCE
There's your bug. You can't do that if you want to stay portable, thus
you must find another feature test macro for whatever feature you are
looking for.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld
On Sun, Aug 25, 2019 at 3:49 PM Hal Murray via devel
wrote:
> I think it should be fixed for the release, but I don't know how to do it.
>
> There used to be code in the msyslog processing that handled %m if it
> wasn't
> included in the local printf. I'm guessing it was removed to eliminate
> w
I think it should be fixed for the release, but I don't know how to do it.
There used to be code in the msyslog processing that handled %m if it wasn't
included in the local printf. I'm guessing it was removed to eliminate
warnings on some systems that don't support %m.
All the %m cases were c
24 matches
Mail list logo
