gcc 8 demanded patch (from NetBSD)
The following patch was recently added to NetBSD, to appease GCC 8 (apparently) ... "hit" is a bool, and it seems gcc 8 does not like ++ operators applied to one of those. (deleted parts of the diff which just showed the version ID string being updated...) kre Index: src/lib/libc/time/localtime.c diff -u src/lib/libc/time/localtime.c:1.106 src/lib/libc/time/localtime.c:1.107 --- src/lib/libc/time/localtime.c:1.106 Sat Mar 11 18:23:14 2017 +++ src/lib/libc/time/localtime.c Tue May 9 02:30:49 2017 @@ -1716,7 +1716,7 @@ timesub(const time_t *timep, int_fast32_ sp->lsis[i - 1].ls_trans + 1 && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { - ++hit; + hit = true; --i; } }
It looks like "hit" erroneously became a bool in commit "Use bool for boolean <https://github.com/eggert/tz/commit/7eb7c7349c80e28c531b65d7d196a1bac279aa1c...>" on Aug 20, 2014. It shouldn't be one. That ++hit is within a loop that would execute should there be a double (or triple ...) leap. Admittedly, there has never been a double leap, and the powers-that-be would probably change the "end of June/December" rule first should we get close to needing one before leap seconds are abolished altogether, but that doesn't mean we shouldn't simply allow for them. On Tue, May 9, 2017 at 8:23 PM, Robert Elz <kre@munnari.oz.au> wrote:
The following patch was recently added to NetBSD, to appease GCC 8 (apparently) ... "hit" is a bool, and it seems gcc 8 does not like ++ operators applied to one of those.
(deleted parts of the diff which just showed the version ID string being updated...)
kre
Index: src/lib/libc/time/localtime.c diff -u src/lib/libc/time/localtime.c:1.106 src/lib/libc/time/localtime.c: 1.107 --- src/lib/libc/time/localtime.c:1.106 Sat Mar 11 18:23:14 2017 +++ src/lib/libc/time/localtime.c Tue May 9 02:30:49 2017 @@ -1716,7 +1716,7 @@ timesub(const time_t *timep, int_fast32_ sp->lsis[i - 1].ls_trans + 1 && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { - ++hit; + hit = true; --i; } }
Date: Tue, 9 May 2017 22:48:55 -0400 From: Bradley White <bww@acm.org> Message-ID: <CAGb2eRMkfxntv3ubHD75U8K975=YMD+Otd7i8z_+dj94Ckg5ww@mail.gmail.com> | It looks like "hit" erroneously became a bool in commit "Use bool for | boolean Then a fix for that would be better... | Admittedly, there has never been a double leap, There never will be, that "double leap second" myth was born from a misunderstanding about "there may be two leap seconds in one year" (which meant one at the end of June, and one at the end of December, but was interpreted to mean that there might be two at the same time.) Any code, anywhere, that is allowing for either 56, 57, 0, 1, 2 or 57, 58, 59, 60, 61, 0, 1, 2 should simply be blast from orbit. kre
On Wed 2017-05-10T11:31:45 +0700, Robert Elz hath writ:
| Admittedly, there has never been a double leap,
There never will be, that "double leap second" myth was born from a misunderstanding about "there may be two leap seconds in one year" (which meant one at the end of June, and one at the end of December, but was interpreted to mean that there might be two at the same time.)
Any code, anywhere, that is allowing for either 56, 57, 0, 1, 2 or 57, 58, 59, 60, 61, 0, 1, 2 should simply be blast from orbit.
Never say never. In 1969 CCIR Interim Working Party 7/1 produced CCIR Plenary Assembly Document VII/1008, and that allowed for multiple leap seconds. The change to remove multiple leap seconds from that document was made on 1970-02-03 in the open discussion during the 13th plenary session of 12th Plenary Assembly of the CCIR. Thus it became CCIR Recommendation 460, now evolved into the current version ITU-R TF.460-6. It is very hard to say what the ITU-R might or might not do. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On 05/10/2017 09:35 AM, Steve Allen wrote:
It is very hard to say what the ITU-R might or might not do.
Yes, and in the long run the current tz master is untenable, as it follows the current ITU rules of at most one leap second per month (it actually enforces 28 days minus 1 second). If I've calculated things correctly, in ~1400 years tidal friction will mean the average day will be about 33 ms longer than it is now, and if we continued to follow the current rules we'd need to insert a leap second roughly every 1/0.033 days, or about once every 30 days. There wouldn't be enough months in the year to insert all the leap seconds that we'd need. Something will have to give.
Date: Wed, 10 May 2017 16:29:15 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <cfe0e56a-6661-faac-4c32-f9d1435a314b@cs.ucla.edu> | If I've calculated things correctly, in ~1400 years [...] | Something will have to give. I shall be looking forward to observing that happen... kre
| If I've calculated things correctly, in ~1400 years [...] | Something will have to give. Y34C? @dashdashado On Wed, May 10, 2017 at 10:13 PM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Wed, 10 May 2017 16:29:15 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <cfe0e56a-6661-faac-4c32-f9d1435a314b@cs.ucla.edu>
| If I've calculated things correctly, in ~1400 years [...] | Something will have to give.
I shall be looking forward to observing that happen...
kre
On 2017-05-10 10:35, Steve Allen wrote:
On Wed 2017-05-10T11:31:45 +0700, Robert Elz hath writ:
Admittedly, there has never been a double leap, There never will be, that "double leap second" myth was born from a misunderstanding about "there may be two leap seconds in one year" (which meant one at the end of June, and one at the end of December, but was interpreted to mean that there might be two at the same time.) Any code, anywhere, that is allowing for either 56, 57, 0, 1, 2 or 57, 58, 59, 60, 61, 0, 1, 2 should simply be blast from orbit. Never say never. In 1969 CCIR Interim Working Party 7/1 produced CCIR Plenary Assembly Document VII/1008, and that allowed for multiple leap seconds. The change to remove multiple leap seconds from that document was made on 1970-02-03 in the open discussion during the 13th plenary session of 12th Plenary Assembly of the CCIR. Thus it became CCIR Recommendation 460, now evolved into the current version ITU-R TF.460-6. It is very hard to say what the ITU-R might or might not do.
...other than produce more "standards" which most governments, licensed broadcasters, and commercial equipment designers selectively or totally ignore when impractical or uneconomic. Does or can anyone now use and trust broadcast time or frequency signals, other than as low quality backup sources suitable for syncing clocks and watches, for those who still like the familiarity of antiquated displays, such as the politicians and judges who legislate "solar" civil time? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Robert Elz said:
The following patch was recently added to NetBSD, to appease GCC 8 (apparently) ... "hit" is a bool, and it seems gcc 8 does not like ++ operators applied to one of those.
Hmm. It's legal, but it suggests dubious thinking on the part of whoever wrote it. It's exactly equivalent to "q = true". ("q--" is equivalent to "q = !q".) -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On May 10, 2017, at 6:33 AM, Clive D.W. Feather <clive@davros.org> wrote:
Robert Elz said:
The following patch was recently added to NetBSD, to appease GCC 8 (apparently) ... "hit" is a bool, and it seems gcc 8 does not like ++ operators applied to one of those.
Hmm. It's legal, but it suggests dubious thinking on the part of whoever wrote it. It's exactly equivalent to "q = true".
As long as you do it fewer than 2^{number of bits in q} times. If q is a 32-bit variable, it's probably safe, but I still prefer "q = true", both for readability reasons and "there is no corner case where it doesn't do what you want" reasons - even if it's known that you'll increment it only once, as the "readability reasons" still apply.
("q--" is equivalent to "q = !q".)
As long as q is 0 or 1, if it's being treated as a traditional C "Boolean". But, again, for both readability and corner-case reasons, I'd avoid it. And "legal but suggests dubious thinking" is a lot of what GCC/clang/etc. warnings are all about - they're not illegal, so they're not errors by default, although GCC, clang, and probably other compilers can be told to treat them as errors.
Date: Thu, 11 May 2017 01:50:14 -0700 From: Guy Harris <guy@alum.mit.edu> Message-ID: <0C3A5981-83B4-4453-84C3-DF940EA70502@alum.mit.edu> | On May 10, 2017, at 6:33 AM, Clive D.W. Feather <clive@davros.org> wrote: | > Hmm. It's legal, but it suggests dubious thinking on the part of whoever | > wrote it. It's exactly equivalent to "q = true". | | As long as you do it fewer than 2^{number of bits in q} times. I have no idea why we are still discussing this ... it has already been made quite clear that the problem really was that the var wasn't supposed to be a bool, but an int, and that the code in question wasn't supposed to be setting it to 1 (which assigning true would do) but 2 (it was already 1 - the code was in a section that started: if (hit) ... What's more, Paul has already written code to make the whole thing go away. When I sent in the original report, I hadn't bothered looking at the code, just the patch (which has now been corrected in NetBSD). kre
Robert Elz said:
I have no idea why we are still discussing this ...
Because it's a programming point that can confuse people. If it's pointed out here, we're less likely to get future proposals making the same mistake.
What's more, Paul has already written code to make the whole thing go away.
Good. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Guy Harris said:
Robert Elz said:
The following patch was recently added to NetBSD, to appease GCC 8 (apparently) ... "hit" is a bool, and it seems gcc 8 does not like ++ operators applied to one of those.
Hmm. It's legal, but it suggests dubious thinking on the part of whoever wrote it. It's exactly equivalent to "q = true".
As long as you do it fewer than 2^{number of bits in q} times.
No, q is a bool. When you assign to a bool any non-zero value is converted to 1. So you only need to consider the cases of 0 and 1, both of which will be changed to 1. More precisely, the statement "q++;" is equivalent to: q = (q + 1) != 0 ? 1 : 0; or: q = (q + 1) != 0; Whether q is 0 or 1 (the only two values it can have), this sets q to 1.
("q--" is equivalent to "q = !q".) As long as q is 0 or 1, if it's being treated as a traditional C "Boolean".
No, again I'm talking about the "bool" type in C. (Technically, the type is called "_Bool" and the header <stdbool.h> contains "#define bool _Bool".)
And "legal but suggests dubious thinking" is a lot of what GCC/clang/etc. warnings are all about
Indeed; I'm not objecting to the warning, quite the contrary. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
participants (8)
-
Arthur David Olson -
Bradley White -
Brian Inglis -
Clive D.W. Feather -
Guy Harris -
Paul Eggert -
Robert Elz -
Steve Allen