Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
My tests show (with recent glibc version) that with TZ=UTC mktime will return -1 for tm_isdst=1. For tm_isdst=0 and tm_isdst=-1 mktime returns the same value. IMHO, tm_isdst=0 makes the most sense for TZ=UTC as UTC does not support DST. On Wed, Apr 21, 2021 at 6:50 PM Richard Cochran wrote: > On Wed, Apr 21, 2021 at 11:51:55AM +, Geva, Erez wrote: > > Looks like the man page is not accurate. > > Looking in > https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html > > Okay, I see now, in the man page we read: > >The value specified in the tm_isdst field informs mktime() whether > or >not daylight saving time (DST) is in effect for the time supplied > in >the tm structure: a positive value means DST is in effect; zero > means >that DST is not in effect; and a negative value means that > mktime() >should (use timezone information and system databases to) attempt > to >determine whether DST is in effect at the specified time. > > So the only input values are -1, 0, and 1. > > Can anybody tell me what glibc will do with TZ=UTC ? > > IOW, should tm_isdst be passed as 0 or -1 ? > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
On Wed, Apr 21, 2021 at 07:28:59PM +0200, Lars Munch wrote: > My tests show (with recent glibc version) that with TZ=UTC mktime will > return -1 for tm_isdst=1. For tm_isdst=0 and tm_isdst=-1 mktime returns the > same value. > > IMHO, tm_isdst=0 makes the most sense for TZ=UTC as UTC does not support > DST. Okay, sounds good. Thanks for following up. Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
On Wed, Apr 21, 2021 at 11:51:55AM +, Geva, Erez wrote: > Looks like the man page is not accurate. > Looking in > https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html Okay, I see now, in the man page we read: The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time. So the only input values are -1, 0, and 1. Can anybody tell me what glibc will do with TZ=UTC ? IOW, should tm_isdst be passed as 0 or -1 ? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
That make sense. nmea uses UTC. UTC does not use daylight saving. So we should set tm_isdst to zero or negative. I think zero is better as UTC should not use daylight saving. Sound like a good ground for a patch Erez From: Lars Munch Sent: Wednesday, 21 April 2021 15:01 To: Geva, Erez (ext) (DI PA DCP R 3) Cc: Richard Cochran ; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc My Arch system does indeed have daylight saving set, but nmea.c forces the TZ to UTC where a positive value of tm_isdst does not make sense. On Wed, Apr 21, 2021 at 1:51 PM Geva, Erez mailto:erez.geva@siemens.com>> wrote: Looks like the man page is not accurate. Looking in https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Ffunctions%2Fmktime.html=04%7C01%7Cerez.geva.ext%40siemens.com%7Cda8de2bf9a9b49318d0b08d904c59709%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546069391715822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=%2F7zfn0tJyfjfQRFOJTRUMa4pxhfSeWh%2FR4ikHOK%2BPeU%3D=0> A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time. My guess is that on Lars new system the daylight is NOT set, then the mktime fail to determine the Daylight Savings and return error (-1). Erez -Original Message- From: Richard Cochran mailto:richardcoch...@gmail.com>> Sent: Tuesday, 20 April 2021 16:05 To: Lars Munch mailto:l...@segv.dk>> Cc: linuxptp-devel@lists.sourceforge.net<mailto:linuxptp-devel@lists.sourceforge.net> Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote: > tm_isdst needs to be initialized to make sure mktime does not fail or > calculates the wrong time. No, take a look at the mktime(3) man page. There you will read the following. The mktime() function modifies the fields of the tm structure as fol‐ lows: tm_wday and tm_yday are set to values determined from the con‐ tents of the other fields; if structure members are outside their valid interval, they will be normalized (so that, for example, 40 Oc‐ tober is changed into 9 November); tm_isdst is set (regardless of its initial value) to a positive value or to 0, respectively, to indicate whether DST is or is not in effect at the specified time. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C6b9d88bf27584b2d9eb508d9040556d6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637545243247255579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wHxP0yERXKP6unOP1ZPV%2F87BVduutafEUIOl8jH%2Bud4%3Dreserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel=04%7C01%7Cerez.geva.ext%40siemens.com%7Cda8de2bf9a9b49318d0b08d904c59709%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637546069391725818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=fAigqGaS7r%2FSyDhqtebI4bmYmfHq0Mp0evVhlko7M9c%3D=0> ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
Looks like you daylight time is broken on Arch Linux and Ubuntu 20.04.
-1 is error by mktime.
Why do you think it is related here?
Fix you daylight time setting in your system and open a bug report in the
relevant packages/systems.
Erez
From: Lars Munch
Sent: Tuesday, 20 April 2021 22:24
To: Michael Galassi
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in
nmea_scan_rmc
Sorry for the noise. In my previous example I had by accident pasted a huge
number into the example. New example:
#include
#include
#include
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
setenv("TZ", "UTC", 1);
t.tm_isdst = 1;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
Gives:
-1
1618956512
1618956512
This is on my up-to-date Arch Linux and Ubuntu 20.04.
On my Ubuntu 18.04 it's fine.
On Tue, Apr 20, 2021 at 5:55 PM Lars Munch mailto:l...@segv.dk>>
wrote:
Ok, so mktime is forced to return in time UTC time scale earlier in the code:
#include
#include
#include
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
setenv("TZ", "UTC", 1);
t.tm_isdst = 41;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
1618941220
1618941220
1618941220
So my problem might come from the fact that I do not have any timezone database
on my system.
On Tue, Apr 20, 2021 at 5:30 PM Lars Munch mailto:l...@segv.dk>>
wrote:
Indeed, any positive random number in tm.tm_isdst will set DST in effect it
seems.
On my stripped down ARM system with no timezone information, it will simply
return -1.
On Tue, Apr 20, 2021 at 4:26 PM Michael Galassi
mailto:mich...@galassi.us>> wrote:
Somewhere lies a bug. The following code snippet:
#include
#include
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
t.tm_isdst = 1;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
Yields:
1618928503
1618932103
1618932103
This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.
-michael
On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran
mailto:richardcoch...@gmail.com>> wrote:
On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> tm_isdst needs to be initialized to make sure mktime does not fail
> or calculates the wrong time.
No, take a look at the mktime(3) man page. There you will read the
following.
The mktime() function modifies the fields of the tm structure as fol‐
lows: tm_wday and tm_yday are set to values determined from the con‐
tents of the other fields; if structure members are outside their
valid interval, they will be normalized (so that, for example, 40 Oc‐
tober is changed into 9 November); tm_isdst is set (regardless of its
initial value) to a positive value or to 0, respectively, to indicate
whether DST is or is not in effect at the specified time.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel=04%7C01%7Cerez.geva.ext%40siemens.com%7Cde9347c617d04ae9efce08d9043a60db%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637545471634930017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=TZg3VXyc2Y0CUpCUOWt3bY5%2Fr8l5VdbXmfErnxXz5EA%3D=0>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
My Arch system does indeed have daylight saving set, but nmea.c forces the TZ to UTC where a positive value of tm_isdst does not make sense. On Wed, Apr 21, 2021 at 1:51 PM Geva, Erez wrote: > Looks like the man page is not accurate. > Looking in > https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html > > A positive or 0 value for tm_isdst shall cause mktime() to presume > initially that Daylight Savings Time, respectively, is or is not in effect > for the specified time. > A negative value for tm_isdst shall cause mktime() to attempt to determine > whether Daylight Savings Time is in effect for the specified time. > > My guess is that on Lars new system the daylight is NOT set, then the > mktime fail to determine the Daylight Savings and return error (-1). > > Erez > > -Original Message- > From: Richard Cochran > Sent: Tuesday, 20 April 2021 16:05 > To: Lars Munch > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in > nmea_scan_rmc > > On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote: > > tm_isdst needs to be initialized to make sure mktime does not fail or > > calculates the wrong time. > > No, take a look at the mktime(3) man page. There you will read the > following. > >The mktime() function modifies the fields of the tm structure as > fol‐ >lows: tm_wday and tm_yday are set to values determined from the > con‐ >tents of the other fields; if structure members are outside > their >valid interval, they will be normalized (so that, for example, 40 > Oc‐ >tober is changed into 9 November); tm_isdst is set (regardless of > its >initial value) to a positive value or to 0, respectively, to > indicate >whether DST is or is not in effect at the specified time. > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C6b9d88bf27584b2d9eb508d9040556d6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637545243247255579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wHxP0yERXKP6unOP1ZPV%2F87BVduutafEUIOl8jH%2Bud4%3Dreserved=0 > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
>From the bug reports:
"tm_isdst == 1 for UTC is invalid input for mktime" which makes perfect
sense.
See:
https://bugzilla.redhat.com/show_bug.cgi?id=1653340
https://sourceware.org/bugzilla/show_bug.cgi?id=24630
Seems glibc changed behaviour recently and my fix is perfectly valid.
On Wed, Apr 21, 2021 at 1:33 PM Geva, Erez
wrote:
> Looks like you daylight time is broken on Arch Linux and Ubuntu 20.04.
>
> -1 is error by mktime.
>
>
>
> Why do you think it is related here?
>
>
>
> Fix you daylight time setting in your system and open a bug report in the
> relevant packages/systems.
>
>
>
> Erez
>
>
>
>
>
> *From:* Lars Munch
> *Sent:* Tuesday, 20 April 2021 22:24
> *To:* Michael Galassi
> *Cc:* linuxptp-devel@lists.sourceforge.net
> *Subject:* Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in
> nmea_scan_rmc
>
>
>
> Sorry for the noise. In my previous example I had by accident pasted a
> huge number into the example. New example:
>
>
>
> #include
> #include
> #include
>
> int main()
> {
> struct tm t;
> time_t now = time((void*)0);
> localtime_r(, );
> setenv("TZ", "UTC", 1);
> t.tm_isdst = 1;
> printf("%ld\n", mktime());
> t.tm_isdst = 0;
> printf("%ld\n", mktime());
> t.tm_isdst = -1;
> printf("%ld\n", mktime());
> }
>
>
>
> Gives:
>
> -1
> 1618956512
> 1618956512
>
>
>
> This is on my up-to-date Arch Linux and Ubuntu 20.04.
>
> On my Ubuntu 18.04 it's fine.
>
>
>
>
>
> On Tue, Apr 20, 2021 at 5:55 PM Lars Munch wrote:
>
> Ok, so mktime is forced to return in time UTC time scale earlier in the
> code:
>
>
>
> #include
> #include
> #include
>
> int main()
> {
> struct tm t;
> time_t now = time((void*)0);
> localtime_r(, );
> setenv("TZ", "UTC", 1);
> t.tm_isdst = 41;
> printf("%ld\n", mktime());
> t.tm_isdst = 0;
> printf("%ld\n", mktime());
> t.tm_isdst = -1;
> printf("%ld\n", mktime());
> }
>
>
>
> 1618941220
> 1618941220
> 1618941220
>
>
>
> So my problem might come from the fact that I do not have any timezone
> database on my system.
>
>
>
>
>
>
>
>
>
> On Tue, Apr 20, 2021 at 5:30 PM Lars Munch wrote:
>
> Indeed, any positive random number in tm.tm_isdst will set DST in effect
> it seems.
>
>
>
> On my stripped down ARM system with no timezone information, it will
> simply return -1.
>
>
>
> On Tue, Apr 20, 2021 at 4:26 PM Michael Galassi
> wrote:
>
> Somewhere lies a bug. The following code snippet:
>
> #include
> #include
> int main()
> {
> struct tm t;
> time_t now = time((void*)0);
> localtime_r(, );
> t.tm_isdst = 1;
> printf("%ld\n", mktime());
> t.tm_isdst = 0;
> printf("%ld\n", mktime());
> t.tm_isdst = -1;
> printf("%ld\n", mktime());
> }
>
> Yields:
>
> 1618928503
> 1618932103
> 1618932103
>
> This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.
>
>
>
> -michael
>
>
>
> On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran
> wrote:
>
> On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> > tm_isdst needs to be initialized to make sure mktime does not fail
> > or calculates the wrong time.
>
> No, take a look at the mktime(3) man page. There you will read the
> following.
>
>The mktime() function modifies the fields of the tm structure as
> fol‐
>lows: tm_wday and tm_yday are set to values determined from the
> con‐
>tents of the other fields; if structure members are outside
> their
>valid interval, they will be normalized (so that, for example, 40
> Oc‐
>tober is changed into 9 November); tm_isdst is set (regardless of
> its
>initial value) to a positive value or to 0, respectively, to
> indicate
>whether DST is or is not in effect at the specified time.
>
> Thanks,
> Richard
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel=04%7C01%7Cerez.geva.ext%40siemens.com%7Cde9347c617d04ae9efce08d9043a60db%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637545471634930017%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=TZg3VXyc2Y0CUpCUOWt3bY5%2Fr8l5VdbXmfErnxXz5EA%3D=0>
>
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
Looks like the man page is not accurate. Looking in https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time. My guess is that on Lars new system the daylight is NOT set, then the mktime fail to determine the Daylight Savings and return error (-1). Erez -Original Message- From: Richard Cochran Sent: Tuesday, 20 April 2021 16:05 To: Lars Munch Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote: > tm_isdst needs to be initialized to make sure mktime does not fail or > calculates the wrong time. No, take a look at the mktime(3) man page. There you will read the following. The mktime() function modifies the fields of the tm structure as fol‐ lows: tm_wday and tm_yday are set to values determined from the con‐ tents of the other fields; if structure members are outside their valid interval, they will be normalized (so that, for example, 40 Oc‐ tober is changed into 9 November); tm_isdst is set (regardless of its initial value) to a positive value or to 0, respectively, to indicate whether DST is or is not in effect at the specified time. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-develdata=04%7C01%7Cerez.geva.ext%40siemens.com%7C6b9d88bf27584b2d9eb508d9040556d6%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637545243247255579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wHxP0yERXKP6unOP1ZPV%2F87BVduutafEUIOl8jH%2Bud4%3Dreserved=0 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
I think that no matter what any particular implementation might do, we are
relying on undefined behavior which is at best unsafe. I wonder if maybe
we shouldn't consider initializing the entire structure (and all others?)
after it is allocated. The performance price feels small and the safety
guarantee feels large.
On Tue, Apr 20, 2021 at 1:24 PM Lars Munch wrote:
> Sorry for the noise. In my previous example I had by accident pasted a
> huge number into the example. New example:
>
> #include
> #include
> #include
>
> int main()
> {
> struct tm t;
> time_t now = time((void*)0);
> localtime_r(, );
> setenv("TZ", "UTC", 1);
> t.tm_isdst = 1;
> printf("%ld\n", mktime());
> t.tm_isdst = 0;
> printf("%ld\n", mktime());
> t.tm_isdst = -1;
> printf("%ld\n", mktime());
> }
>
> Gives:
> -1
> 1618956512
> 1618956512
>
> This is on my up-to-date Arch Linux and Ubuntu 20.04.
> On my Ubuntu 18.04 it's fine.
>
>
> On Tue, Apr 20, 2021 at 5:55 PM Lars Munch wrote:
>
>> Ok, so mktime is forced to return in time UTC time scale earlier in the
>> code:
>>
>> #include
>> #include
>> #include
>>
>> int main()
>> {
>> struct tm t;
>> time_t now = time((void*)0);
>> localtime_r(, );
>> setenv("TZ", "UTC", 1);
>> t.tm_isdst = 41;
>> printf("%ld\n", mktime());
>> t.tm_isdst = 0;
>> printf("%ld\n", mktime());
>> t.tm_isdst = -1;
>> printf("%ld\n", mktime());
>> }
>>
>> 1618941220
>> 1618941220
>> 1618941220
>>
>> So my problem might come from the fact that I do not have any timezone
>> database on my system.
>>
>>
>>
>>
>> On Tue, Apr 20, 2021 at 5:30 PM Lars Munch wrote:
>>
>>> Indeed, any positive random number in tm.tm_isdst will set DST in effect
>>> it seems.
>>>
>>> On my stripped down ARM system with no timezone information, it will
>>> simply return -1.
>>>
>>> On Tue, Apr 20, 2021 at 4:26 PM Michael Galassi
>>> wrote:
>>>
Somewhere lies a bug. The following code snippet:
#include
#include
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
t.tm_isdst = 1;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
Yields:
1618928503
1618932103
1618932103
This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.
-michael
On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran <
richardcoch...@gmail.com> wrote:
> On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> > tm_isdst needs to be initialized to make sure mktime does not fail
> > or calculates the wrong time.
>
> No, take a look at the mktime(3) man page. There you will read the
> following.
>
>The mktime() function modifies the fields of the tm structure
> as fol‐
>lows: tm_wday and tm_yday are set to values determined from
> the con‐
>tents of the other fields; if structure members are
> outside their
>valid interval, they will be normalized (so that, for example,
> 40 Oc‐
>tober is changed into 9 November); tm_isdst is set (regardless
> of its
>initial value) to a positive value or to 0, respectively, to
> indicate
>whether DST is or is not in effect at the specified time.
>
> Thanks,
> Richard
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
Sorry for the noise. In my previous example I had by accident pasted a huge
number into the example. New example:
#include
#include
#include
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
setenv("TZ", "UTC", 1);
t.tm_isdst = 1;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
Gives:
-1
1618956512
1618956512
This is on my up-to-date Arch Linux and Ubuntu 20.04.
On my Ubuntu 18.04 it's fine.
On Tue, Apr 20, 2021 at 5:55 PM Lars Munch wrote:
> Ok, so mktime is forced to return in time UTC time scale earlier in the
> code:
>
> #include
> #include
> #include
>
> int main()
> {
> struct tm t;
> time_t now = time((void*)0);
> localtime_r(, );
> setenv("TZ", "UTC", 1);
> t.tm_isdst = 41;
> printf("%ld\n", mktime());
> t.tm_isdst = 0;
> printf("%ld\n", mktime());
> t.tm_isdst = -1;
> printf("%ld\n", mktime());
> }
>
> 1618941220
> 1618941220
> 1618941220
>
> So my problem might come from the fact that I do not have any timezone
> database on my system.
>
>
>
>
> On Tue, Apr 20, 2021 at 5:30 PM Lars Munch wrote:
>
>> Indeed, any positive random number in tm.tm_isdst will set DST in effect
>> it seems.
>>
>> On my stripped down ARM system with no timezone information, it will
>> simply return -1.
>>
>> On Tue, Apr 20, 2021 at 4:26 PM Michael Galassi
>> wrote:
>>
>>> Somewhere lies a bug. The following code snippet:
>>> #include
>>> #include
>>> int main()
>>> {
>>> struct tm t;
>>> time_t now = time((void*)0);
>>> localtime_r(, );
>>> t.tm_isdst = 1;
>>> printf("%ld\n", mktime());
>>> t.tm_isdst = 0;
>>> printf("%ld\n", mktime());
>>> t.tm_isdst = -1;
>>> printf("%ld\n", mktime());
>>> }
>>> Yields:
>>> 1618928503
>>> 1618932103
>>> 1618932103
>>> This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.
>>>
>>> -michael
>>>
>>> On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran <
>>> richardcoch...@gmail.com> wrote:
>>>
On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> tm_isdst needs to be initialized to make sure mktime does not fail
> or calculates the wrong time.
No, take a look at the mktime(3) man page. There you will read the
following.
The mktime() function modifies the fields of the tm structure
as fol‐
lows: tm_wday and tm_yday are set to values determined from
the con‐
tents of the other fields; if structure members are outside
their
valid interval, they will be normalized (so that, for example,
40 Oc‐
tober is changed into 9 November); tm_isdst is set (regardless
of its
initial value) to a positive value or to 0, respectively, to
indicate
whether DST is or is not in effect at the specified time.
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>>>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
Indeed, any positive random number in tm.tm_isdst will set DST in effect it
seems.
On my stripped down ARM system with no timezone information, it will simply
return -1.
On Tue, Apr 20, 2021 at 4:26 PM Michael Galassi wrote:
> Somewhere lies a bug. The following code snippet:
> #include
> #include
> int main()
> {
> struct tm t;
> time_t now = time((void*)0);
> localtime_r(, );
> t.tm_isdst = 1;
> printf("%ld\n", mktime());
> t.tm_isdst = 0;
> printf("%ld\n", mktime());
> t.tm_isdst = -1;
> printf("%ld\n", mktime());
> }
> Yields:
> 1618928503
> 1618932103
> 1618932103
> This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.
>
> -michael
>
> On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran
> wrote:
>
>> On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
>> > tm_isdst needs to be initialized to make sure mktime does not fail
>> > or calculates the wrong time.
>>
>> No, take a look at the mktime(3) man page. There you will read the
>> following.
>>
>>The mktime() function modifies the fields of the tm structure as
>> fol‐
>>lows: tm_wday and tm_yday are set to values determined from the
>> con‐
>>tents of the other fields; if structure members are outside
>> their
>>valid interval, they will be normalized (so that, for example, 40
>> Oc‐
>>tober is changed into 9 November); tm_isdst is set (regardless of
>> its
>>initial value) to a positive value or to 0, respectively, to
>> indicate
>>whether DST is or is not in effect at the specified time.
>>
>> Thanks,
>> Richard
>>
>>
>> ___
>> Linuxptp-devel mailing list
>> Linuxptp-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>>
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
Ok, so mktime is forced to return in time UTC time scale earlier in the
code:
#include
#include
#include
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
setenv("TZ", "UTC", 1);
t.tm_isdst = 41;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
1618941220
1618941220
1618941220
So my problem might come from the fact that I do not have any timezone
database on my system.
On Tue, Apr 20, 2021 at 5:30 PM Lars Munch wrote:
> Indeed, any positive random number in tm.tm_isdst will set DST in effect
> it seems.
>
> On my stripped down ARM system with no timezone information, it will
> simply return -1.
>
> On Tue, Apr 20, 2021 at 4:26 PM Michael Galassi
> wrote:
>
>> Somewhere lies a bug. The following code snippet:
>> #include
>> #include
>> int main()
>> {
>> struct tm t;
>> time_t now = time((void*)0);
>> localtime_r(, );
>> t.tm_isdst = 1;
>> printf("%ld\n", mktime());
>> t.tm_isdst = 0;
>> printf("%ld\n", mktime());
>> t.tm_isdst = -1;
>> printf("%ld\n", mktime());
>> }
>> Yields:
>> 1618928503
>> 1618932103
>> 1618932103
>> This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.
>>
>> -michael
>>
>> On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran
>> wrote:
>>
>>> On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
>>> > tm_isdst needs to be initialized to make sure mktime does not fail
>>> > or calculates the wrong time.
>>>
>>> No, take a look at the mktime(3) man page. There you will read the
>>> following.
>>>
>>>The mktime() function modifies the fields of the tm structure as
>>> fol‐
>>>lows: tm_wday and tm_yday are set to values determined from the
>>> con‐
>>>tents of the other fields; if structure members are outside
>>> their
>>>valid interval, they will be normalized (so that, for example,
>>> 40 Oc‐
>>>tober is changed into 9 November); tm_isdst is set (regardless
>>> of its
>>>initial value) to a positive value or to 0, respectively, to
>>> indicate
>>>whether DST is or is not in effect at the specified time.
>>>
>>> Thanks,
>>> Richard
>>>
>>>
>>> ___
>>> Linuxptp-devel mailing list
>>> Linuxptp-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>>>
>>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
Somewhere lies a bug. The following code snippet:
#include
#include
int main()
{
struct tm t;
time_t now = time((void*)0);
localtime_r(, );
t.tm_isdst = 1;
printf("%ld\n", mktime());
t.tm_isdst = 0;
printf("%ld\n", mktime());
t.tm_isdst = -1;
printf("%ld\n", mktime());
}
Yields:
1618928503
1618932103
1618932103
This is true on FreeBSD 13 and Ubuntu 18.04, both fully patched.
-michael
On Tue, Apr 20, 2021 at 7:04 AM Richard Cochran
wrote:
> On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote:
> > tm_isdst needs to be initialized to make sure mktime does not fail
> > or calculates the wrong time.
>
> No, take a look at the mktime(3) man page. There you will read the
> following.
>
>The mktime() function modifies the fields of the tm structure as
> fol‐
>lows: tm_wday and tm_yday are set to values determined from the
> con‐
>tents of the other fields; if structure members are outside
> their
>valid interval, they will be normalized (so that, for example, 40
> Oc‐
>tober is changed into 9 November); tm_isdst is set (regardless of
> its
>initial value) to a positive value or to 0, respectively, to
> indicate
>whether DST is or is not in effect at the specified time.
>
> Thanks,
> Richard
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH] Fix uninitialized variable in nmea_scan_rmc
On Tue, Apr 20, 2021 at 11:44:06AM +0200, Lars Munch wrote: > tm_isdst needs to be initialized to make sure mktime does not fail > or calculates the wrong time. No, take a look at the mktime(3) man page. There you will read the following. The mktime() function modifies the fields of the tm structure as fol‐ lows: tm_wday and tm_yday are set to values determined from the con‐ tents of the other fields; if structure members are outside their valid interval, they will be normalized (so that, for example, 40 Oc‐ tober is changed into 9 November); tm_isdst is set (regardless of its initial value) to a positive value or to 0, respectively, to indicate whether DST is or is not in effect at the specified time. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
