svn commit: r322893 - head/bin/dd

[Ian Lepore]

On Fri, 2017-08-25 at 12:09 -0600, Warner Losh wrote:
> On Fri, Aug 25, 2017 at 12:02 PM, Matt Joras <matt.joras at gmail.com>
> wrote:
> 
> > 
> > On 08/25/2017 10:17, Conrad Meyer wrote:
> > > 
> > > This change seems to break buildworld on MIPS:
> > > 
> > > /home/cem/head.svn/bin/dd/args.c: In function 'f_bs':
> > > /home/cem/head.svn/bin/dd/args.c:188: warning: format '%zd'
> > > expects
> > > type 'signed size_t', but argument 3 has type 'long int'
> > > /home/cem/head.svn/bin/dd/args.c: In function 'f_cbs':
> > > /home/cem/head.svn/bin/dd/args.c:199: warning: format '%zd'
> > > expects
> > > type 'signed size_t', but argument 3 has type 'long int'
> > > /home/cem/head.svn/bin/dd/args.c: In function 'f_ibs':
> > > /home/cem/head.svn/bin/dd/args.c:245: warning: format '%zd'
> > > expects
> > > type 'signed size_t', but argument 3 has type 'long int'
> > > /home/cem/head.svn/bin/dd/args.c: In function 'f_obs':
> > > /home/cem/head.svn/bin/dd/args.c:266: warning: format '%zd'
> > > expects
> > > type 'signed size_t', but argument 3 has type 'long int'
> > > 
> > > (Yes, it's odd that the SSIZE_MAX constant has 'long' type.)
> > > 
> > SSIZE_MAX should have type long, since ssize_t is a long on mips
> > (and
> > other arches besides i386 and arm).
> > 
> > Re: the build failure, that's in the GCC C format string checking,
> > so
> > perhaps it's more accurate to say this breaks the (in-tree) GCC
> > build.
> > %zd is the right format specifier for ssize_t. I guess GCC's format
> > string checking is getting confused because SSIZE_MAX is a constant
> > that
> > expands to type long. Perhaps casting to ssize_t would GCC happier,
> > but
> > that looks rather wrong.
> > 
> This is why it was cast in the first place due to issues with exact
> type.
> Maybe we should put the casts back for the printfs.
> 
> Warner

I think the right fix is to define SSIZE_MAX correctly based on the
type of ssize_t.  The x86 and powerpc _limits.h files get this right,
it looks like mips is the only one with both 32 and 64-bit support that
doesn't define SSIZE_MAX based on ssize_t type.

-- Ian