Signed vs Unsigned Warning due to sizeof

Bug #237075 reported by Michael D. Adams
2
Affects Status Importance Assigned to Milestone
Ikarus Scheme
Fix Committed
Medium
Abdulaziz Ghuloum

Bug Description

In src/ikarus-data.h, you have "#define wordsize (sizeof(ikptr))". Now, the "sizeof" operator returns an unsigned value and in C an addition or multiplication between a signed and an unsigned value produced an unsigned value. This means that "align_shift" and "align_size" become unsigned values which ultimately makes the result of "align(n)" an unsigned value.

#define align_shift (wordshift + 1)
#define align_size (2 * wordsize)
#define align(n) \
  ((((n) + align_size - 1) >> align_shift) << align_shift)

This triggers a warning in ikarus-collect.c where you have "assert(size == align(size));" with "size" of type "int". This results in a signed vs unsigned comparison.

I see two ways to fix this. The first is to change wordsize to be "((int)sizeof(ikptr))" which strangely doesn't seem to introduce any extra warnings (I presume since it always gets added to an unsigned value first). The second is to change the type of "size" to be "int", but that depends on whether you intend to pass negative sizes or anything like that.

Revision history for this message
Abdulaziz Ghuloum (aghuloum) wrote : Re: [Bug 237075] [NEW] Signed vs Unsigned Warning due to sizeof

On Jun 3, 2008, at 7:00 AM, Michael D. Adams wrote:
> I see two ways to fix this. The first is to change wordsize to be
> "((int)sizeof(ikptr))" which strangely doesn't seem to introduce any
> extra warnings (I presume since it always gets added to an unsigned
> value first). The second is to change the type of "size" to be "int",
> but that depends on whether you intend to pass negative sizes or
> anything like that.

I think the first way is the correct way of handling this. Sizes
should remain unsigned since the size of a data structure could (in
theory) be larger than 2GB on a 32-bit machine. Such large objects
are currently slightly broken I believe. Will investigate further.

Revision history for this message
Abdulaziz Ghuloum (aghuloum) wrote :

There seems to be a problem evaluating:
  (let ([x (make-vector (greatest-fixnum))]) (vector-length x))
which was fixed by following some of these warnings. Thanks!

Changed in ikarus:
assignee: nobody → aghuloum
importance: Undecided → Medium
status: New → Fix Committed
Revision history for this message
Abdulaziz Ghuloum (aghuloum) wrote :

Now that expression simply doesn't terminate on my machine (not enough ram).

Revision history for this message
Michael D. Adams (mdmkolbe) wrote :

Sorry, I should have said "The second is to change the type of 'size' to be 'unsigned int'" because right now it is an "int".

Changed in ikarus:
milestone: none → 0.0.4
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.