On Fri, 2014-10-31 at 14:30 -0700, Garrett Cooper wrote:
> On Oct 28, 2014, at 4:33, Bruce Evans <b...@optusnet.com.au> wrote:
>
> > On Tue, 28 Oct 2014, [utf-8] Dag-Erling Smørgrav wrote:
> >
> >> Bruce Evans <b...@optusnet.com.au> writes:
> >>> Dag-Erling Smørgrav <d...@des.no> writes:
> >>>> This is a bug on all platforms, and both clang and (recent) gcc
> >>>> should complain about it. That printf() call will print garbage.
> >>> No, this is only a bug on 32-bit arches. The is is SSIZE_MAX.
> >>
> >> If you mean "it only has consequences on 32-bit arches", then I agree -
> >> but it is still a bug to pass an int to %jd.
> >
> > This is machine-dependent. intmax_t may be int. The only requirement
> > on intmax_t is that it can represent any value of any signed integer
> > type. This is possible if the largest integer type is 64 bits (the
> > smallest permitted largest type) and int is also 64 bits (and there
> > are no complications for padding bits). intmax_t can even be signed
> > char if that is wide enough (not in POSIX starting 10-15 years ago,
> > since signed char is now required to be 8 bits. It is weird for
> > intmax_t to have the lowest rank (not counting Bool), but FreeBSD uses
> > this loophole to make it have second highest rank on 64-bit arches.
>
> Indeed. For some giggles, look at this bug:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191674 ("printf("%tu",
> (intmax_t)-1) returns UINT64_MAX on i386, not UINT32_MAX”).
> Cheers,
Isn't the problem in that bug that the cast doesn't match the printf
format, and the correct code would be something like the following?
printf("%tu", (ptrdiff_t)-1);
-- Ian
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
