Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Tue, Jul 25, 2006 at 01:21:44PM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>> > tags 339344 - patch
>> > thanks
>> >
>> > On Mon, Jul 17, 2006 at 09:56:10AM +0200, Goswin Brederlow wrote:
>> >> Package: belpic
>> >> Followup-For: Bug #339344
>> >>
>> >> Hi,
>> >>
>> >> attached is a patch for the pointer conversion error.
>> >
>> > It doesn't actually work, though; you can't change the definition of a
>> > class which is rather central in the entire class hierarchy and hope
>> > that things still compile. Also, this implies an API change, which is a
>> > Very Bad Thing(TM).
>>
>> Worked fine here on amd64. What error do you get?
>
> The exact reverse of what you got on amd64 without the fix.
>
> Unfixed, the code assumed that size_t == unsigned int, and that one cast
> broke on architectures where this is not true.
>
> Your "fix" basically assumed that size_t == unsigned long (the code
> refers to that modified data later on as size_t anyway). It also
My fix assumes size_t is size_t. As you said the data is used as
size_t later on and I just made it declare the argument as size_t
instead of unsigned long.
You probably run into problems on the calling side of the function
where someone used an unsigned long pointer instead of a size_t
pointer. That is why I asked for the error.
> happened to change the ABI (not just the API) of the library, which
> would have required me to do a SONAME bump (the function was part of an
> abstract class, and many child classes reimplement it).
The API/ABI change was always a given for me.
>> > The right fix is simpler: rather than trying to cast unsigned long to
>> > unsigned int, one should cast unsigned long to size_t (which happens to
>> > be the same thing on 32bit architectures, but nowhere else).
>>
>> That isn't right. That might just be working on the relevant systems.
>
> Sorry, after looking at the code for over three hours, I came to the
> conclusion that it is. Please check the patch and prove to me that it is
> wrong, or it will stay the way it is now.
Consider a system where size_t != unsigned long. I can't name you an
example in Debian but it isn't impossible. Point is that you are
casting the type of a pointer and they may not match.
I'm not sure but I think Mips N32 abi has this case. 32 bit pointers
but 64bit longs, size_t should be 32bit. The software would fail there.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
