Re: tests: cal/bigyear only works on 64bit (sizeof(long) == 8) systems

[Karel Zak <kzak@redhat.com>]

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