avoiding warnings for "legitimate" casts

[Bill Waddington]

Long time lurker, 1st time poster. I hope this is sufficiently
c related. If not, send me to my room.

I'm porting a driver to a 64-bit platform. I get handed a struct:

typedef struct {
...
size_t dmac_size
} ddi_dma_cookie_ t;

On a 64-bit build size_t is 64 bits wide, but all actual values will
fit in a 32 bit variable. Eventually I need to write dmac_size into
a 32-bit device register:

uint32_t dma_count = dma_cookie.dmac _size;

ddi_put32(..., dma_count);

dmac_size is 64 bits wide, ddi_put32 insists on a 32 bit value, so
lint and or the compiler complain about assigning a 64 to a 32. If
I use a cast they complain about casting 64 to 32. The code runs
fine, but I would like a warning-free compile for those cases where
a customer does the compiling.

Is there a "c" way to quiet this kind of warning via casts or passing
through some intermediate variable? Maybe this tool set is too picky.
Tried the FAQ, hope I didn't miss it.

Thanks,
Bill
--
William D Waddington
william.wadding ton@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

[Chris Torek]

Re: avoiding warnings for "legitimat e" casts

In article <9l4q61tlkevjja s4n7hb3trvq2ul9 fo7vu@4ax.com>,
Bill Waddington <william.waddin gton@beezmo.com > wrote:

[my summary: program receives a 64-bit value as a size_t, then
converts it to 32 bit, but the compiler sequence, which apparently
includes running an external "picky" checker, warns for either
ordinary assignment or a cast.]
[color=blue]
>Is there a "c" way to quiet this kind of warning via casts or passing
>through some intermediate variable? Maybe this tool set is too picky.[/color]

No diagnostic is required for either operation, but your
compiler apparently produces one for both. Unless it has some
way to eliminate that particular warning for that particular
line of code (or all code), you are stuck.

If that particular compiler's warning is especially clever, it
is just barely possible that writing, e.g.,:

void f(uint64_t input_val) {
uint32_t shortened_versi on;

if (input_val > 0xffffffff)
panic("impossib ly large input value");
shortened_versi on = input_val;
...
}

might not warn. It is slightly more likely that:

if (input_val > 0xffffffff)
panic("impossib ly large input value");
shortened_versi on = input_val & 0xffffffff;

will not warn. But chances are that the warning will occur no
matter what you do, if both casts and ordinary assignments already
warn.

(Note that using uint32_t, not plain int32_t, is potentially
important here, for portable code. Of course, your code is inherently
non-portable -- inasmuch as the device you are driving is also
non-portable anyway; I would venture to bet that it does not work
on the Univac 1100 series or various Crays, which are capable of
supporting ANSI/ISO C -- so in that sense it does not matter anyway.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Bill Waddington]

Re: avoiding warnings for &quot;legitimat e&quot; casts

On 25 Apr 2005 16:56:03 GMT, Chris Torek <nospam@torek.n et> wrote:
[color=blue]
>In article <9l4q61tlkevjja s4n7hb3trvq2ul9 fo7vu@4ax.com>,
>Bill Waddington <william.waddin gton@beezmo.com > wrote:
>
> [my summary: program receives a 64-bit value as a size_t, then
> converts it to 32 bit, but the compiler sequence, which apparently
> includes running an external "picky" checker, warns for either
> ordinary assignment or a cast.][/color]

Indeed.
[color=blue][color=green]
>>Is there a "c" way to quiet this kind of warning via casts or passing
>>through some intermediate variable? Maybe this tool set is too picky.[/color]
>
>No diagnostic is required for either operation, but your
>compiler apparently produces one for both. Unless it has some
>way to eliminate that particular warning for that particular
>line of code (or all code), you are stuck.[/color]

Figured I was stuck, but my skills are sufficiently feeble that I
thought it best to ask. I can turn off the cast check, but only
globally. Probably not a good idea.
[color=blue]
>If that particular compiler's warning is especially clever, it
>is just barely possible that writing, e.g.,:
>
> void f(uint64_t input_val) {
> uint32_t shortened_versi on;
>
> if (input_val > 0xffffffff)
> panic("impossib ly large input value");
> shortened_versi on = input_val;
> ...
> }
>
>might not warn. It is slightly more likely that:
>
> if (input_val > 0xffffffff)
> panic("impossib ly large input value");
> shortened_versi on = input_val & 0xffffffff;
>
>will not warn. But chances are that the warning will occur no
>matter what you do, if both casts and ordinary assignments already
>warn.[/color]

I'll give this a try, but I'm not optimistic. My best bet is to just
document the warnings in my README I guess.
[color=blue]
>(Note that using uint32_t, not plain int32_t, is potentially
>important here, for portable code. Of course, your code is inherently
>non-portable -- inasmuch as the device you are driving is also
>non-portable anyway; I would venture to bet that it does not work
>on the Univac 1100 series or various Crays, which are capable of
>supporting ANSI/ISO C -- so in that sense it does not matter anyway.)[/color]

Anything with a PCI slot. In this case an Opteron running Solaris 10,
Studio 10 cc and lint.

Portability doesn't matter this time, but I would like to improve
my game re c coding when possible...

Thanks for your time,
Bill
--
William D Waddington
william.wadding ton@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

[Steffen Fiksdal]

Re: avoiding warnings for &quot;legitimat e&quot; casts



On Mon, 25 Apr 2005, Bill Waddington wrote:
[color=blue]
> On 25 Apr 2005 16:56:03 GMT, Chris Torek <nospam@torek.n et> wrote:
>[color=green]
> >In article <9l4q61tlkevjja s4n7hb3trvq2ul9 fo7vu@4ax.com>,
> >Bill Waddington <william.waddin gton@beezmo.com > wrote:
> >
> > [my summary: program receives a 64-bit value as a size_t, then
> > converts it to 32 bit, but the compiler sequence, which apparently
> > includes running an external "picky" checker, warns for either
> > ordinary assignment or a cast.][/color]
>
> Indeed.
>[color=green][color=darkred]
> >>Is there a "c" way to quiet this kind of warning via casts or passing
> >>through some intermediate variable? Maybe this tool set is too picky.[/color]
> >
> >No diagnostic is required for either operation, but your
> >compiler apparently produces one for both. Unless it has some
> >way to eliminate that particular warning for that particular
> >line of code (or all code), you are stuck.[/color]
>
> Figured I was stuck, but my skills are sufficiently feeble that I
> thought it best to ask. I can turn off the cast check, but only
> globally. Probably not a good idea.[/color]

I believe the function you are calling sucks bigtime....

[color=blue][color=green]
> >If that particular compiler's warning is especially clever, it
> >is just barely possible that writing, e.g.,:
> >
> > void f(uint64_t input_val) {
> > uint32_t shortened_versi on;
> >
> > if (input_val > 0xffffffff)
> > panic("impossib ly large input value");
> > shortened_versi on = input_val;
> > ...
> > }
> >
> >might not warn. It is slightly more likely that:
> >
> > if (input_val > 0xffffffff)
> > panic("impossib ly large input value");
> > shortened_versi on = input_val & 0xffffffff;
> >
> >will not warn. But chances are that the warning will occur no
> >matter what you do, if both casts and ordinary assignments already
> >warn.[/color]
>
> I'll give this a try, but I'm not optimistic. My best bet is to just
> document the warnings in my README I guess.[/color]

Yes, document that the function you are calling sucks bigtime...
[color=blue][color=green]
> >(Note that using uint32_t, not plain int32_t, is potentially
> >important here, for portable code. Of course, your code is inherently
> >non-portable -- inasmuch as the device you are driving is also
> >non-portable anyway; I would venture to bet that it does not work
> >on the Univac 1100 series or various Crays, which are capable of
> >supporting ANSI/ISO C -- so in that sense it does not matter anyway.)[/color]
>
> Anything with a PCI slot. In this case an Opteron running Solaris 10,
> Studio 10 cc and lint.
>
> Portability doesn't matter this time, but I would like to improve
> my game re c coding when possible...
>
> Thanks for your time,
> Bill
> --
> William D Waddington
> william.wadding ton@beezmo.com
> "Even bugs...are unexpected signposts on
> the long road of creativity..." - Ken Burtch
>[/color]

[those who know me have no need of my name]

Re: avoiding warnings for &quot;legitimat e&quot; casts

in comp.lang.c i read:

[member dmac_size has type size_t, which is 64 bits on the op's platform]
[color=blue]
>uint32_t dma_count = dma_cookie.dmac _size;[/color]
[color=blue]
>lint and or the compiler complain about assigning a 64 to a 32.[/color]

lints can often be told that the assignment is intentional, and it may be
that your compiler uses the same mechanism so that a single annotation
works for both. this is if you are lucky.

the horrible way to silence the warning if nothing else works may be a
cast:

uint32_t dma_count = (uint32_t)dma_c ookie.dmac_size ;

compilers are allowed to output most anything they like any time they like,
so if nothing works then you'll just have to accept it -- or switch to a
more sensible compiler. lint is there to try to warn about things which
may be risky, so they are supposed to produce warnings if there's any
chance your code might have behavior that can be surprising.

--
a signature

[Jonathan Adams]

Re: avoiding warnings for &quot;legitimat e&quot; casts

In article <9l4q61tlkevjja s4n7hb3trvq2ul9 fo7vu@4ax.com>,
Bill Waddington <william.waddin gton@beezmo.com > wrote:
[color=blue]
> uint32_t dma_count = dma_cookie.dmac _size;
>
> ddi_put32(..., dma_count);
>
> dmac_size is 64 bits wide, ddi_put32 insists on a 32 bit value, so
> lint and or the compiler complain about assigning a 64 to a 32. If
> I use a cast they complain about casting 64 to 32. The code runs
> fine, but I would like a warning-free compile for those cases where
> a customer does the compiling.[/color]

If you can get it so that only lint complains, then you can just put
/* LINTED */
on the line beforehand, to shut lint up.

Cheers,
- jonathan

[Bill Waddington]

Re: avoiding warnings for &quot;legitimat e&quot; casts

On Thu, 28 Apr 2005 05:58:20 -0700, Jonathan Adams <jwadams@gmail. com>
wrote:
[color=blue]
>In article <9l4q61tlkevjja s4n7hb3trvq2ul9 fo7vu@4ax.com>,
> Bill Waddington <william.waddin gton@beezmo.com > wrote:
>[color=green]
>> uint32_t dma_count = dma_cookie.dmac _size;
>>
>> ddi_put32(..., dma_count);
>>
>> dmac_size is 64 bits wide, ddi_put32 insists on a 32 bit value, so
>> lint and or the compiler complain about assigning a 64 to a 32. If
>> I use a cast they complain about casting 64 to 32. The code runs
>> fine, but I would like a warning-free compile for those cases where
>> a customer does the compiling.[/color]
>
>If you can get it so that only lint complains, then you can just put
> /* LINTED */
>on the line beforehand, to shut lint up.
>[/color]

Nuts. I missed that "generic" directive when I dug throught the docs.
I will probably use NOTE(LINTED()) w/this set of tools. Maybe use
a msg arg to print "ignore this..."

Thanks,
Bill
--
William D Waddington
william.wadding ton@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch