Conference turris::decc

2205.0. "CC-W-UNAVOLACC warning missing?" by SSDEVO::ROCHFORD () Thu May 29 1997 13:01

    I understand why the following code reports the CC-W-UNAVOLACC warning 
    when compiled with /nombmer_align. But why doesn't 
    it report this warning if I change the "int" to a "short" in the 
    definition of the my_bits union?  The short should still be considered 
    unaligned shouldn't it?  I've even tried this with my_bits defined as
    as short that expands longword boundaries, and I still do not see the
    CC-W-UNAVOLACC warning.  Why???
    
    typedef volatile struct _my_struct {
            char    start;
            union _my_bits {
                    int     total;
                    struct _bit_layout {
                            int b1 :1;
                            int b25 :4;
                            int bremain :11;
                            } bit_layout;
                    } my_bits;
            int     end;
            }my_struct;
    main()
    {
    my_struct st1;
    st1.my_bits.total=1;
    st1.my_bits.total++;
    }
    
    The following compiles without the warning.
    
    typedef volatile struct _my_struct {
            char    start;
            union _my_bits {
                    short   total;
                    struct _bit_layout {
                            short b1 :1;
                            short b25 :4;
                            short bremain :11;
                            } bit_layout;
                    } my_bits;
            int     end;
            }my_struct;
    main()
    {
    my_struct st1;
    st1.my_bits.total=1;
    st1.my_bits.total++;
    }
    
                                   

The basic issue is that the reference gets expanded into a field reference,
rather than looking like a "typical" scalar reference, and that reference
winds up falling through code pattern selection down to the most general
case, and that case doesn't do the checking.  (This particular message
is emitted very late in the compiler.)

Unfortunately, the checking code isn't currently set up to handle field
references in general, so this will take some work.  I'll post this
in gem_bugs as a low priority item.  (At the point when this was
implemented, it was considered a convenience to users to catch likely
problems, similar to uninitialized variable detection, which also
doesn't warn about all cases.)