Juan Lang <[EMAIL PROTECTED]> writes:
>> Do you feel it's reasonable just to turn on
>> ST_FIX_ALIGN, which *could* mask
>> errors both in wine and in the user's code?
>
> It may indeed. The masking problems in user code
> bothers me, though, since you're using winelib and you
> may not have a pr
--- Eric Frias <[EMAIL PROTECTED]> wrote:
> I did some more reading, and found there's a way to
> get the kernel to
> install a handler for unaligned accesses which will
> synthesize the unaligned
> access with two aligned accesses, and then jump back
> to the original point
> in the code.
Interes
Juan Lang a écrit :
> Yikes. That's a bad one. The trouble is MS loves
> this sort of return value. Even if the dll itself
> doesn't dereference an unaligned pointer, the caller
> might depending on how things are layed out. The
> trouble is i386 allows unaligned memory access, so we
> don't se
Juan Lang a écrit :
I just ran across an evil little bug in the
WINSPOOL_GetPrinter_2 function. It looks like this
type of bug could be hiding in other API functions
too. It causes a segmentation fault because of an
unaligned access on Solaris (sparc).
Yikes. That's a bad one. The trouble is
> I just ran across an evil little bug in the
> WINSPOOL_GetPrinter_2 function. It looks like this
> type of bug could be hiding in other API functions
> too. It causes a segmentation fault because of an
> unaligned access on Solaris (sparc).
Yikes. That's a bad one. The trouble is MS loves
t
I just ran across an evil little bug in the WINSPOOL_GetPrinter_2 function.
It looks like this type of bug could be hiding in other API functions too.
It causes a segmentation fault because of an unaligned access on Solaris
(sparc).
This function packs a PRINTER_INFO_2 structure and all of its
var
