Re: fix the DEVELOPER-HINTS file to reflect how things are really done

[Andreas Mohr]

Hi,

On Fri, Jan 21, 2005 at 04:54:29PM +0900, Mike McCormack wrote:
> ChangeLog:
> - fix the DEVELOPER-HINTS file to reflect how things are really done

Did I miss something?
> -
>   FIXME("(%x,%p,%d): stub\n", hdc, p, count);
> - BOOL WINAPI PolyBezierTo(HDC hdc, const POINT *p, DWORD count)
> - {
> -
>  /* tell the user they've got a substandard implementation */
> -
>  FIXME("%p %p %ld\n", hdc, p, count);

This is a step backwards IMHO.
It doesn't tell squat: the user doesn't know that this is a stub
("FIXME" what??), and he doesn't know that these are supposed to be the
function parameters either (it could be any other variable debug printout,
too - it's indistinguishable).

To developers, such a printout might make sense if it's known to be
the standard format (and I'd say it isn't!), but to people that aren't
fiddling with Wine on a daily basis it will mean less than the previous form.

OTOH, since "stub" is a somewhat nebulous word, too (to non-developers),
it probably makes sense to leave it out (a FIXME does indicate a shortcoming
after all, so such a non-specific output string makes it very likely that
it's the whole function that is broken), but at least keep the braces
that indicate function parameters.

But OTOH, since "... stub" has been in use for ages, its meaning
is probably common knowledge amoung many older Wine users, and it's only
an extra 6 or 7 characters anyway, so I'd still leave it in.

Greetings,

Andreas Mohr

fix the DEVELOPER-HINTS file to reflect how things are really done

[Mike McCormack]

Andreas Mohr wrote:
> > -
> >  FIXME("%p %p %ld\n", hdc, p, count);
>
> This is a step backwards IMHO.
> It doesn't tell squat: the user doesn't know that this is a stub
> ("FIXME" what??), and he doesn't know that these are supposed to be the
> function parameters either (it could be any other variable debug printout,
> too - it's indistinguishable).

Looking at logs tells the user nothing except that there's a problem. 
The only way to figure out why the message is there is to look at the 
code, and it should be pretty obvious if it's a stub or not.

Mike

fix the DEVELOPER-HINTS file to reflect how things are really done

[Alexandre Julliard]

Mike McCormack  writes:
> Looking at logs tells the user nothing except that there's a
> problem. The only way to figure out why the message is there is to
> look at the code, and it should be pretty obvious if it's a stub or
> not.

Well no, it's not always obvious, and there really isn't any harm in
stating what the FIXME is for. I don't think making error messages
more obscure is a step forward.

fix the DEVELOPER-HINTS file to reflect how things are really done

[Michael Stefaniuc]

Mike McCormack wrote:
> Andreas Mohr wrote:
> > > -
> > >  FIXME("%p %p %ld\n", hdc, p, count);
> >
> > This is a step backwards IMHO.
> > It doesn't tell squat: the user doesn't know that this is a stub
> > ("FIXME" what??), and he doesn't know that these are supposed to be the
> > function parameters either (it could be any other variable debug 
> > printout,
> > too - it's indistinguishable).
>
> Looking at logs tells the user nothing except that there's a problem. 
> The only way to figure out why the message is there is to look at the 
> code, and it should be pretty obvious if it's a stub or not.

I wonder how http://www.winehq.org/site/winapi_stats is generated and if 
it checks for the word "stub" in the FIXME's too for the detection of 
"pseudo-stubs". As the stubs are eliminated from the spec files checking 
for the stubs would have to happen only in the code. Functions that do 
not return STATUS_NOT_IMPLEMENTED or do not do the appropiate 
SetLastError(ERROR_CALL_NOT_IMPLEMENTED) call would need the "stub" 
message in the FIXME. Unless we consider the informations in 
http://www.winehq.org/site/winapi_stats to not be worth the effort.

bye
    michael