On Mon, Jan 06, 2014 at 12:55:08PM +0000, Sami Kerola wrote:
> On 6 January 2014 12:30, Karel Zak <kzak@xxxxxxxxxx> 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@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
