* tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems
@ 2013-12-23 2:42 Mike Frysinger
2014-01-06 12:30 ` Karel Zak
0 siblings, 1 reply; 6+ messages in thread
From: Mike Frysinger @ 2013-12-23 2:42 UTC (permalink / raw)
To: util-linux
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]
the cal bigyear test uses a year of 1234567890123456789, but the parsing logic
reads it in like so:
year = strtol_or_err(*argv++, _("illegal year value"));
that's a signed long type, so on 32bit systems, you get:
cal: Year 1234567890123456789 ...cal: illegal year value:
'1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
cal: illegal year value: '1234567890123456789': Numerical result out of range
FAILED (cal/bigyear)
should the test detect the sizeof(long) and then calculate a number that is
smaller than that ?
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems 2013-12-23 2:42 tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems Mike Frysinger @ 2014-01-06 12:30 ` Karel Zak 2014-01-06 12:55 ` Sami Kerola 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2014-01-06 12:30 UTC (permalink / raw) To: Mike Frysinger; +Cc: util-linux, Sami Kerola On Sun, Dec 22, 2013 at 09:42:43PM -0500, Mike Frysinger wrote: > the cal bigyear test uses a year of 1234567890123456789, but the parsing logic > reads it in like so: > year = strtol_or_err(*argv++, _("illegal year value")); > > that's a signed long type, so on 32bit systems, you get: > cal: Year 1234567890123456789 ...cal: illegal year value: > '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > cal: illegal year value: '1234567890123456789': Numerical result out of range > FAILED (cal/bigyear) > > should the test detect the sizeof(long) and then calculate a number that is > smaller than that ? It would be better to keep cal(1) arch insensitive. Sami, why we need so huge year numbers and why the number is signed? I guess it would be enough to use "unsigned int" (UINT_MAX is 4294967295). Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems 2014-01-06 12:30 ` Karel Zak @ 2014-01-06 12:55 ` Sami Kerola 2014-01-06 13:08 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: Sami Kerola @ 2014-01-06 12:55 UTC (permalink / raw) To: Karel Zak; +Cc: Mike Frysinger, util-linux On 6 January 2014 12:30, Karel Zak <kzak@redhat.com> wrote: > On Sun, Dec 22, 2013 at 09:42:43PM -0500, Mike Frysinger wrote: >> that's a signed long type, so on 32bit systems, you get: >> cal: Year 1234567890123456789 ...cal: illegal year value: >> >> should the test detect the sizeof(long) and then calculate a number that is >> smaller than that ? > > It would be better to keep cal(1) arch insensitive. > > Sami, why we need so huge year numbers and why the number is signed? > I guess it would be enough to use "unsigned int" (UINT_MAX is 4294967295). Hi Mike & Karel, Year was left signed because someone said it might be interesting to know pre-year-zero outputs. After a bit research the pre-zero year calendars are theoretical construct, mostly because agreement in western world is not more than couple hundred years old. That means pre-zero calendar could only be considered as a what a modern western people think the calendar should have looked. Whether that is valuable, interesting, useful, etc is a different question. Meanwhile the big year test is clearly broken. I recon there should be a version for various sizes of INT_MAX tests, and depending how large values are supported by system corresponding tests are ran. -- Sami Kerola http://www.iki.fi/kerolasa/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems 2014-01-06 12:55 ` Sami Kerola @ 2014-01-06 13:08 ` Karel Zak 2014-01-06 23:21 ` Sami Kerola 0 siblings, 1 reply; 6+ messages in thread From: Karel Zak @ 2014-01-06 13:08 UTC (permalink / raw) To: kerolasa; +Cc: Mike Frysinger, util-linux On Mon, Jan 06, 2014 at 12:55:08PM +0000, Sami Kerola wrote: > On 6 January 2014 12:30, Karel Zak <kzak@redhat.com> wrote: > > On Sun, Dec 22, 2013 at 09:42:43PM -0500, Mike Frysinger wrote: > >> that's a signed long type, so on 32bit systems, you get: > >> cal: Year 1234567890123456789 ...cal: illegal year value: > >> > >> should the test detect the sizeof(long) and then calculate a number that is > >> smaller than that ? > > > > It would be better to keep cal(1) arch insensitive. > > > > Sami, why we need so huge year numbers and why the number is signed? > > I guess it would be enough to use "unsigned int" (UINT_MAX is 4294967295). > > Hi Mike & Karel, > > Year was left signed because someone said it might be interesting to > know pre-year-zero outputs. After a bit research the pre-zero year > calendars are theoretical construct, mostly because agreement in but the code is: #define SMALLEST_YEAR 1 if (ctl.req.year < SMALLEST_YEAR) errx(EXIT_FAILURE, _("illegal year value: use positive integer")); > western world is not more than couple hundred years old. That means > pre-zero calendar could only be considered as a what a modern western > people think the calendar should have looked. Whether that is > valuable, interesting, useful, etc is a different question. > > Meanwhile the big year test is clearly broken. I recon there should be > a version for various sizes of INT_MAX tests, and depending how large > values are supported by system corresponding tests are ran. INT_MAX is the same everywhere, all you need is to remove arch specific "long" from the code and use strtos32_or_err() to parse the year number. (Well, I guess that 2147483647 years is enough :-) Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems 2014-01-06 13:08 ` Karel Zak @ 2014-01-06 23:21 ` Sami Kerola 2014-01-13 12:02 ` Karel Zak 0 siblings, 1 reply; 6+ messages in thread From: Sami Kerola @ 2014-01-06 23:21 UTC (permalink / raw) To: Karel Zak; +Cc: Mike Frysinger, util-linux On 6 January 2014 13:08, Karel Zak <kzak@redhat.com> wrote: > On Mon, Jan 06, 2014 at 12:55:08PM +0000, Sami Kerola wrote: >> Year was left signed because someone said it might be interesting to >> know pre-year-zero outputs. After a bit research the pre-zero year >> calendars are theoretical construct, mostly because agreement in > > but the code is: > > #define SMALLEST_YEAR 1 > > if (ctl.req.year < SMALLEST_YEAR) > errx(EXIT_FAILURE, _("illegal year value: use positive integer")); Hi Karel, That is correct right now. If negative years are allowed to be used I'm sure bug reports will follow. The leap year printouts are obviously wrong. >> Meanwhile the big year test is clearly broken. I recon there should be >> a version for various sizes of INT_MAX tests, and depending how large >> values are supported by system corresponding tests are ran. > > INT_MAX is the same everywhere, all you need is to remove arch > specific "long" from the code and use strtos32_or_err() to parse the > year number. > > (Well, I guess that 2147483647 years is enough :-) Use of 32 bit int is indeed the easiest fix, and I'm all in favor of cutting the cal output there. -- Sami Kerola http://www.iki.fi/kerolasa/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems 2014-01-06 23:21 ` Sami Kerola @ 2014-01-13 12:02 ` Karel Zak 0 siblings, 0 replies; 6+ messages in thread From: Karel Zak @ 2014-01-13 12:02 UTC (permalink / raw) To: kerolasa; +Cc: Mike Frysinger, util-linux On Mon, Jan 06, 2014 at 11:21:03PM +0000, Sami Kerola wrote: > On 6 January 2014 13:08, Karel Zak <kzak@redhat.com> wrote: > > On Mon, Jan 06, 2014 at 12:55:08PM +0000, Sami Kerola wrote: > >> Year was left signed because someone said it might be interesting to > >> know pre-year-zero outputs. After a bit research the pre-zero year > >> calendars are theoretical construct, mostly because agreement in > > > > but the code is: > > > > #define SMALLEST_YEAR 1 > > > > if (ctl.req.year < SMALLEST_YEAR) > > errx(EXIT_FAILURE, _("illegal year value: use positive integer")); > > Hi Karel, > > That is correct right now. If negative years are allowed to be used > I'm sure bug reports will follow. The leap year printouts are > obviously wrong. > > >> Meanwhile the big year test is clearly broken. I recon there should be > >> a version for various sizes of INT_MAX tests, and depending how large > >> values are supported by system corresponding tests are ran. > > > > INT_MAX is the same everywhere, all you need is to remove arch > > specific "long" from the code and use strtos32_or_err() to parse the > > year number. > > > > (Well, I guess that 2147483647 years is enough :-) > > Use of 32 bit int is indeed the easiest fix, and I'm all in favor of > cutting the cal output there. OK, I'm going to wait for the patch :-) Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-01-13 12:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-23 2:42 tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems Mike Frysinger 2014-01-06 12:30 ` Karel Zak 2014-01-06 12:55 ` Sami Kerola 2014-01-06 13:08 ` Karel Zak 2014-01-06 23:21 ` Sami Kerola 2014-01-13 12:02 ` Karel Zak
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox