On Fri, Sep 11, 2015 at 03:10:05PM +0300, Dmitry V. Levin wrote:
> On Fri, Sep 11, 2015 at 01:39:29PM +0200, Patrik Jakobsson wrote:
> > On Wed, Sep 09, 2015 at 01:50:40AM +0300, Dmitry V. Levin wrote:
> > > On Mon, Aug 24, 2015 at 02:42:50PM +0200, Patrik Jakobsson wrote:
> > > > +static int drm_mode_create_dumb(struct tcb *tcp, const unsigned int code, long arg)
> > > > +{
> > > > + struct drm_mode_create_dumb dumb;
> > > > +
> > > > + if (umove(tcp, arg, &dumb))
> > > > + return RVAL_DECODED;
> > > > +
> > > > + if (entering(tcp)) {
> > > > + tprintf(", {width=%u, height=%u, bpp=%u, flags=0x%x",
> > > > + dumb.width, dumb.height, dumb.bpp, dumb.flags);
> > > > + } else if (exiting(tcp)) {
> > > > + tprintf(", handle=%u, pitch=%u, size=%Lu}", dumb.handle,
> > > > + dumb.pitch, dumb.size);
> > > > + }
> > > > +
> > > > + return RVAL_DECODED | 1;
> > > > +}
> > >
> > > This generates a warning (which turns into an error with
> > > --enable-gcc-Werror) on x86_64 when using kernel drm headers:
> > >
> > > drm.c: In function 'drm_mode_create_dumb':
> > > drm.c:521:11: error: format '%Lu' expects argument of type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' [-Werror=format=]
> >
> > So this brings us back to whether to include drm kernel headers or not. If
> > -Werror is a requirement (which is already broken last time I checked) there
>
> Is it? Could you cite the error, please?
It's in aio.c:185 which at a closer look is intentional. Would still break the
build though. But I'm not arguing that letting warnings slip through (with or
without -Werror) is ok, just wondering if it justifies what I'm trying to do
here.
> > will need to be #ifdefs at various places in drm decoding. What would you
> > prefer. Both options are fine by me.
>
> This is the only place where definitions differ to the extent that it's visible.
> I'd rather cast the argument to unsigned long long.
Sounds reasonable, I'll do that.
>
> --
> ldv
> ------------------------------------------------------------------------------
> _______________________________________________
> Strace-devel mailing list
> Strace-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/strace-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
