Re: [ros-dev] [ros-diffs] [jimtabor] 37436: - Fixes bug 3864. While I was at it I fixed most of the gdi max bit max info sizes too. - Added notes for the SEH abuse in win32k dibobj.c. - Tested WinMerge 2.10.2, AbiWord 2.4.1, Firefox 1.5.0.3 and wine

[James Tabor]

These are correct changes.

On Tue, Nov 18, 2008 at 10:34 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>   May I ask why those if (!Info) checks are required? To
> me it makes no
>  sense to call those APIs with the cruicial, mandatory working (and in
>  one case the only) parameter being NULL, and I would put an ASSERT
>  (Info) there to catch bad callers and fix them.
>
>  WBR,
>  Aleksey.
>
>  On Nov 18, 2008, at 8:36 AM, jimtabor(a)svn.reactos.org wrote:
>
> >   Author: jimtabor
> >  Date: Mon Nov 17 23:36:19 2008
> >  New Revision: 37436
> >
> >   UINT
> >   FASTCALL
> >   DIB_BitmapMaxBitsSize( PBITMAPINFO Info, UINT ScanLines )
> >   {
> >       UINT MaxBits = 0;
> >  +
> >  +    if (!Info) return 0;
> >
> >
> >  +UINT
> >  +FASTCALL
> >  +DIB_BitmapBitsSize( PBITMAPINFO Info )
> >  +{
> >  +  UINT Ret;
> >  +
> >  +  if (!Info) return 0; 
>

[Aleksey Bragin]

Very explanative :-)

I didn't ask whether they are correct, if you committed them, it's  
enough to think it was intentional and correct. I asked *why* such  
strange guards (read: hacks) in our code are needed? And is not it  
better to fix bad callers instead, maybe it's on your todo list, I  
don't know.

If it's by design, then allright, let's mark it as IN OPTIONAL  
parameter and that's it.


WBR,
Aleksey.

On Nov 19, 2008, at 3:37 AM, James Tabor wrote:

>   These are correct changes.
>
>  On Tue, Nov 18, 2008 at 10:34 AM, Aleksey Bragin  
>  <aleksey(a)reactos.org> wrote:
> > May I ask why those if (!Info) checks are required? To me it makes no
> > sense to call those APIs with the cruicial, mandatory working (and in
> > one case the only) parameter being NULL, and I would put an ASSERT
> > (Info) there to catch bad callers and fix them.
> >
> > WBR,
> > Aleksey.
> >
> > On Nov 18, 2008, at 8:36 AM, jimtabor(a)svn.reactos.org wrote:
> >
> >> Author: jimtabor
> >> Date: Mon Nov 17 23:36:19 2008
> >> New Revision: 37436
> >>
> >>  UINT
> >>  FASTCALL
> >>  DIB_BitmapMaxBitsSize( PBITMAPINFO Info, UINT ScanLines )
> >>  {
> >>      UINT MaxBits = 0;
> >> +
> >> +    if (!Info) return 0;
> >>
> >>
> >> +UINT
> >> +FASTCALL
> >> +DIB_BitmapBitsSize( PBITMAPINFO Info )
> >> +{
> >> +  UINT Ret;
> >> +
> >> +  if (!Info) return 0;
> >

[James Tabor]

Hi,

Well the code subroutines have safeguards placed in them. We know this
due to research and trial studies. These safeguards are located in
target and most called functions.

A good example of an emulation hack that I have seen is this:

if(!bmi){
   if(bits) *bits = NULL;
   return NULL;
}

Taken from wine (Do I need to post copyright notice for this too Mr.
Edwards?), function CreateDIBSection.

This is a behavioral hack to emulate the correct test case results for
this function.

 UINT
 FASTCALL
 DIB_BitmapMaxBitsSize( PBITMAPINFO Info, UINT ScanLines )
  {
      UINT MaxBits = 0;

    if (!Info) return 0;

UINT
FASTCALL
DIB_BitmapBitsSize( PBITMAPINFO Info )
{
  UINT Ret;

  if (!Info) return 0;

These are magnificently correct and create an one byte allocated space
with RtlAllocateHeap as it should and pass the one byte pointer to
kernel space since this is also correct behavior for most these
related kernel space functions. Zero bytes are copied and the kernel
functions with defaults settings and it passes or fails in kernel
space. Which is why we are correcting kernel space function behavior.

I am very surprised you did not know this,,,, read the code train,,,
James

puzzled, B^/

[Aleksey Bragin]

Thanks a lot, we're not only 2 people working on the project - in  
case someone has a desire to remove it.. I would give him this to  
read :-)


On Nov 19, 2008, at 7:35 PM, James Tabor wrote:

>   Hi,
>
>  Well the code subroutines have safeguards placed in them. We know this
>  due to research and trial studies. These safeguards are located in
>  target and most called functions.
>
>  A good example of an emulation hack that I have seen is this:
>
>  if(!bmi){
>     if(bits) *bits = NULL;
>     return NULL;
>  }
>
>  Taken from wine (Do I need to post copyright notice for this too Mr.
>  Edwards?), function CreateDIBSection.
>
>  This is a behavioral hack to emulate the correct test case results for
>  this function.
>
>   UINT
>   FASTCALL
>   DIB_BitmapMaxBitsSize( PBITMAPINFO Info, UINT ScanLines )
>    {
>        UINT MaxBits = 0;
>
>      if (!Info) return 0;
>
>  UINT
>  FASTCALL
>  DIB_BitmapBitsSize( PBITMAPINFO Info )
>  {
>    UINT Ret;
>
>    if (!Info) return 0;
>
>  These are magnificently correct and create an one byte allocated space
>  with RtlAllocateHeap as it should and pass the one byte pointer to
>  kernel space since this is also correct behavior for most these
>  related kernel space functions. Zero bytes are copied and the kernel
>  functions with defaults settings and it passes or fails in kernel
>  space. Which is why we are correcting kernel space function behavior.
>
>  I am very surprised you did not know this,,,, read the code train,,,
>  James
>
>  puzzled, B^/