[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] 7 failures and 1 error in test suite
- To: pygame-users@xxxxxxxx
- Subject: Re: [pygame] 7 failures and 1 error in test suite
- From: René Dudfield <renesd@xxxxxxxxx>
- Date: Thu, 2 Jul 2009 09:48:48 +1000
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: pygame-users-outgoing@xxxxxxxx
- Delivered-to: pygame-users@xxxxxxxx
- Delivery-date: Wed, 01 Jul 2009 19:48:51 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=DF9S+7KqgfkTlzvpE2aBjRixilQc7yWgirIayHSPgqs=; b=kUYGhsIAgiELcF8WpcxOCc6Zol2t9nCp29gARs6FW2zh2hPAe/1W9H3+hAkjGWguHM GrDu65oAn+NCdS6Lk/ANcnc6GoTAeSheuFbznWRZGTPYVi/UoGr6f/7MMIHXd1TZIkQh VR56H/iqDT7ZgOIiJ0+uuowSTkzbkoCAu3240=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=o5FFJ+RhNfe5GlXXytwRWyGQMrI3VYKHEKdPOm59por+fi7oq4+YFWqoafrnvYxsBR DKjMVa1AnWH08Ae4iFn9h7WB7fMm0qCuYm1+MKJcOkBrXwk7wiOi2iO7v6fPPBg2VsoA 3+zD8F9gRDX9EgMAkDJq7MV3QWKAqYH2YOqXA=
- In-reply-to: <4A4BEEFE.6070003@xxxxxxxxxxxxxxxxx>
- References: <4A4BD633.5020201@xxxxxxxxxxxxxxxxx> <4A4BEEFE.6070003@xxxxxxxxxxxxxxxxx>
- Reply-to: pygame-users@xxxxxxxx
- Sender: owner-pygame-users@xxxxxxxx
Cool, thanks for the testing.
On Thu, Jul 2, 2009 at 9:19 AM, Lorenz Quack<don@xxxxxxxxxxxxxxxxx> wrote:
> Ok, so here goes my analysis of the failures in ColorTypeTest:
> In src/color.c line 1435 (and some following lines) we bit shift each color
> component and stuff them
> in an unsigned long.
Maybe this should be into a uint32 instead?
> I think the problem arises when we bitshift the r value and r is >127
> My guess is that C converts r to an integer during the bitshift and not to
> an unsigned int so
> if r > 127 the integer (r is shifted by 24) overflows and becomes negative
> (note that the internal
> bit representation of the int has not changed) but when we store this
> (negative) integer into a
> long it remains negative so the first bits get filled up with "1"s.
> I see different solutions to this and cant decide which is the _correct_ one
> so I'll just present them
> instead:
> 1) don't save the combined color in an unsigned long. use a unsigned int
> instead.
> This should work as long as r, g, b, a are UInt8 and aren't shifted more
> than 24
> 2) explicitly cast the r value to be unsigned
> 3) cast the r value to be (unsigned) long
>
> furthermore I think in the we should compare tmp to UINT_MAX in line 1438,
> 1476 and 1492.
> even though I haven't put much thought into this at least then the tests
> don't fail.
>