On Nov 6, 2007, at 7:44 AM, Ralf S. Engelschall wrote:

> On Tue, Nov 06, 2007, Jeff Johnson wrote:
>
>> This assumes typeof(flp->fl_mode) == typeof(matchpathcon arg).
>
> Yes, I was under the impression that the argument to matchpathcon is a
> "mode_t" (according to at least http://linux.die.net/man/3/ 
> matchpathcon)
> and "fl_mode" is an alias for "struct stat"'s "st_mode" which in
> turn is defined (at least by POSIX) to be also of type "mode_t"
> (http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/ 
> stat.h.html).
>
> So, this change should be just fine. At least the change should  
> make no
> difference because in ISO-C AFAIK...
>
>   foo_t foo = bar;
>   foo_xxx(foo);
>
> causes the value of "bar" coerced into "foo_t" exactly the same way  
> as in:
>
>   foo_xxx(bar);
>
> At least as long as the proper prototype
>
>   extern [...] foo_xxx(foo_t arg);
>
> is present, of course. If "bar" is not already of type "foo_t" or a
> fully compatible type which can be implicitly coerced, we would get a
> warning in both situations, of course.
>

The change *IS* fine.

However, a very common problem in rpm (3 episodes since May on PLD/ 
sparc64),
is with endianness, alignment, types, ptrs of items that get promoted  
to int.

I'm just planting the memory so that I will recognize the problem  
when I eventually
get to overhauling build/files.c. The flp structure is ancient  
history dating back to
rpm-1.0 when rpm was written in perl.

73 de Jeff