Re: Portability problem with SCM_DEBUG_TYPING_STRICTNESS=1

[Matthias Koeppe]

Dirk Herrmann <address@hidden> writes:

> On 8 Jun 2001, Matthias Koeppe wrote:
> 
> > "unif.c", line 1927: a cast does not yield an lvalue
> 
> (hopefully) fixed.

It works, thanks!

> > The compiler also reports integer overflows:
> > 
> > "goops.c", line 557: warning: integer overflow detected: op "<<"
> > [...]
> > 
> > They can be resolved by the following patch: 
> > 
> > Index: struct.h
> > ===================================================================
> > RCS file: /cvs/guile/guile-core/libguile/struct.h,v
> > retrieving revision 1.37
> > diff -u -u -r1.37 struct.h
> > --- struct.h        2001/05/27 22:00:03     1.37
> > +++ struct.h        2001/06/08 08:54:38
> > @@ -72,9 +72,9 @@
> >  
> >  typedef size_t (*scm_struct_free_t) (scm_bits_t * vtable, scm_bits_t * 
> > data);
> >  
> > -#define SCM_STRUCTF_MASK   (0xFFF << 20)
> > -#define SCM_STRUCTF_ENTITY (1L << 30) /* Indicates presence of proc slots 
> > */
> > -#define SCM_STRUCTF_LIGHT  (1L << 31) /* Light representation
> > +#define SCM_STRUCTF_MASK   (0xFFFUL << 20)
> > +#define SCM_STRUCTF_ENTITY (1UL << 30) /* Indicates presence of proc slots 
> > */
> > +#define SCM_STRUCTF_LIGHT  (1UL << 31) /* Light representation
> >                                      (no hidden words) */
> 
> In this case, I think we should wait until scm_t_bits is made into an
> unsigned type.  Then, instead of writing 0xFFFUL we should probably write
> (scm_t_bits) 0xFFF.  Currently, as long as scm_t_bits is signed, this
> wouldn't solve your problem.

Yes it does solve the problem because the integer overflow happens at
shift time, not at assignment time.  0xFFF << 20 has the 31st bit set,
so it does not fit into a signed 32-bit integer. 0xFFFU << 20,
however, is a nice unsigned 32-bit integer; assigning it to a
scm_bits_t location does not cause an error or warning, whether
scm_bits_t is unsigned or not.

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe