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 :
> So static storage items are initialized for at least C11.
To zeros. It would be *deeply* shocking and break all manner of code
if a C compiler ever failed to enforce that.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description:
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 Ian!
On Thu, 29 Aug 2019 17:16:11 -0500
Ian Bruene via devel wrote:
> On 8/29/19 4:36 PM, Gary E. Miller via devel wrote:
> > Hal you are corect. Page 140, section 6.7.9 Initialization.
> >
> > "If an object that has static or thread storage duration is not
> > initialized explicitly, then:
On 8/29/19 4:36 PM, Gary E. Miller via devel wrote:
Hal you are corect. Page 140, section 6.7.9 Initialization.
"If an object that has static or thread storage duration is not initialized
explicitly, then:
[...]
-- if it has arithmetic tye, it is initialized to (positive or unsigned)
zero;"
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
Yo All!
Warnings on OSX:
[ 73/131] Compiling libntp/ntp_calendar.c
../../ntpd/ntp_control.c:2612:27: warning: format specifies type 'unsigned
short' but the argument has type 'unsigned int' [-Wformat]
socktoa(rmt_addr), (unsigned)SRCPORT(rmt_addr));
Yo Hal!
> On Thu, 29 Aug 2019 14:06:25 -0700
> Hal Murray via devel wrote:
>
> > >> By "floating", you mean uninnitialized? In C that's going to
> > >> mean it's
> > false
> >
> > > Yes. My understanding of C is that anything not explicitly set has
> > > whatever random value happens to
Yo Hal!
On Thu, 29 Aug 2019 14:06:25 -0700
Hal Murray via devel wrote:
> >> By "floating", you mean uninnitialized? In C that's going to mean
> >> it's
> false
>
> > Yes. My understanding of C is that anything not explicitly set has
> > whatever random value happens to be in that memory loc
>> By "floating", you mean uninnitialized? In C that's going to mean it's
false
> Yes. My understanding of C is that anything not explicitly set has whatever
> random value happens to be in that memory location. Possibly changed if
> certain unknown compiler options are chosen.
I thought g
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
On 8/29/19 3:46 PM, Eric S. Raymond wrote:
By "floating", you mean uninnitialized? In C that's going to mean it's false
Yes. My understanding of C is that anything not explicitly set has
whatever random value happens to be in that memory location. Possibly
changed if certain unknown compil
Ian Bruene via devel :
>
> The other day I determined that the flag disable_dynamic_updates (currently
> in the io_data struct) is either not properly initialized, or is blocking
> off a large chunk of dead code. After reading through the relevant code and
> looking through the history I think it
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
The other day I determined that the flag disable_dynamic_updates
(currently in the io_data struct) is either not properly initialized, or
is blocking off a large chunk of dead code. After reading through the
relevant code and looking through the history I think it is the former:
The flag is
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:07:47 +0200
Achim Gratz via devel wrote:
> Sanjeev Gupta via devel writes:
> > Gary, ALPN string checking. The commit mentioned that it would
> > break with previous NTPSec versions.
>
> But it doesn't, because the returned protocol was not checked.
> Otherwi
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
22 matches
Mail list logo
