Some leftover bugs for this release

Some leftover bugs for this release

[Mike Gran]

Hi-

I guess according to the schedule there is another point release tomorow.

Just a couple of notes.

As it stands, we know the netbsd amd64 build will fail for reasons
discussed in 
http://lists.gnu.org/archive/html/guile-devel/2009-08/msg00213.html

Also, the netbsd build will likely fail because there is new
'condition is always true' condition in array-handle.c:103

100 SCM
101 scm_array_handle_element_type (scm_t_array_handle *h)
102 {
103   if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
104     abort (); /* guile programming error */
105   return scm_i_array_element_types[h->element_type];
106 }

I'd fix it myself, but, I'm away from non-work keyboard.

Thanks,

Mike

Re: Some leftover bugs for this release

[Ludovic Courtès]

Hi,

Mike Gran <spk121@yahoo.com> writes:

> Also, the netbsd build will likely fail because there is new
> 'condition is always true' condition in array-handle.c:103
>
> 100 SCM
> 101 scm_array_handle_element_type (scm_t_array_handle *h)
> 102 {
> 103   if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
> 104     abort (); /* guile programming error */
> 105   return scm_i_array_element_types[h->element_type];
> 106 }

Hmm, an enum variable can possibly hold any integer value, so why would
this always be true?  Are you actually hitting this?

Thanks,
Ludo’.

Re: Some leftover bugs for this release

[Mike Gran]

> From: Ludovic Courtès <ludo@gnu.org>
> 
> Hi,
> 
> Mike Gran writes:
> 
> > Also, the netbsd build will likely fail because there is new
> > 'condition is always true' condition in array-handle.c:103
> >
> > 100 SCM
> > 101 scm_array_handle_element_type (scm_t_array_handle *h)
> > 102 {
> > 103 
>   if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
> > 104     abort (); /* guile programming error */
> > 105   return scm_i_array_element_types[h->element_type];
> > 106 }
> 
> Hmm, an enum variable can possibly hold any integer value, so why would
> this always be true?  Are you actually hitting this?

I poked around the gcc source code to see under what conditions the
"comparison is always true due to limited range of data type" warnings
occur.  These are the ones that NetBSD gcc seems to have and that
my gcc doesn't have.  For them to occur, it seems that the Wtype-limits
warning option must be active on that platform, but, not on mine.

I tried to figure out why this was so by looking at some of the BSD
CVS trees, but, I couldn't find out where this was enabled by default.
I'm not that familiar with the the organization of the BSD sources, though.

So when I enable -Wtype-limits on my build, it warns for any enum
value that is beyond those enumerated in the type definition.  The 
smallest value in this enum is zero, hence the warning.

[Insert standard rant about using -Werror here.]

Thanks,

Mike

Re: Some leftover bugs for this release

[Ludovic Courtès]

Hi Mike,

Mike Gran <spk121@yahoo.com> writes:

>> > Also, the netbsd build will likely fail because there is new
>> > 'condition is always true' condition in array-handle.c:103
>> >
>> > 100 SCM
>> > 101 scm_array_handle_element_type (scm_t_array_handle *h)
>> > 102 {
>> > 103 
>>   if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
>> > 104     abort (); /* guile programming error */
>> > 105   return scm_i_array_element_types[h->element_type];
>> > 106 }
>> 
>> Hmm, an enum variable can possibly hold any integer value, so why would
>> this always be true?  Are you actually hitting this?

[...]

> So when I enable -Wtype-limits on my build, it warns for any enum
> value that is beyond those enumerated in the type definition.  The 
> smallest value in this enum is zero, hence the warning.

Then we could just use ‘-Wtype-limits’ and remove the above run-time
check.  Andy?

Thanks,
Ludo’.

Re: Some leftover bugs for this release

[Andy Wingo]

Hi,

On Wed 16 Sep 2009 11:09, ludo@gnu.org (Ludovic Courtès) writes:

>>> > 100 SCM
>>> > 101 scm_array_handle_element_type (scm_t_array_handle *h)
>>> > 102 {
>>> > 103 
>>>   if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
>>> > 104     abort (); /* guile programming error */
>>> > 105   return scm_i_array_element_types[h->element_type];
>>> > 106 }
>>> 
>>> Hmm, an enum variable can possibly hold any integer value, so why would
>>> this always be true?  Are you actually hitting this?
>
> [...]
>
>> So when I enable -Wtype-limits on my build, it warns for any enum
>> value that is beyond those enumerated in the type definition.  The 
>> smallest value in this enum is zero, hence the warning.
>
> Then we could just use ‘-Wtype-limits’ and remove the above run-time
> check.  Andy?

The struct could get corrupted somehow of course. It's not a bad check,
but the typechecker is working against us :P

Andy
-- 
http://wingolog.org/

Re: Some leftover bugs for this release

[Andy Wingo]

On Wed 16 Sep 2009 02:20, Mike Gran <spk121@yahoo.com> writes:

> [Insert standard rant about using -Werror here.]

We should not be making releases with -Werror.

Andy
-- 
http://wingolog.org/