My Wine static analysis tool

[Damjan Jovanovic]

Hi

I've hacked together a simple tool for analyzing Wine code. Currently
it can do the following:
1. Find BOOL functions returning non-BOOL.
2. Find HRESULT functions returning non-HRESULTs.
3. Generate a TRACE() for each function showing all its parameters.

It isn't really a formal C parser, as it ignores all preprocessor
directives, but this makes it *much* simpler and shorter than a real C
parser, and it sees original Windows types like LPCWSTR etc. It's not
100% accurate, but it's very effective. 3 of my recent patches have
been generated with its help - and I've barely gotten started.

I'd like to add the following features at some stage:
* Populate all functions with a TRACE() of their arguments, if they
don't already have it.
* Scan all GUIDs in include/ and generate a full list of all GUIDs and
their names. Then patch debugstr_guid() to also output the name of the
GUID when available, and/or search and replace GUIDs in WINEDEBUG
traces after they've been recorded.
* Update .spec files from .c file contents, and verify .spec file accuracy.
* It could be extended to examine contents of functions and enforce
the absence of W->A and 32->16 calls, etc.
* etc.

Anybody interested in using it or helping develop it?

Regards
Damjan

[Alexandre Julliard]

Damjan Jovanovic  writes:
> I'd like to add the following features at some stage:
> - Populate all functions with a TRACE() of their arguments, if they
>
> don't already have it.

Please don't do that. There are many functions that we don't need to
trace, or that already have traces in sub-functions, or where it's
really the return value that's interesting, etc.

[André Hentschel]

Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
> Hi
>
> I've hacked together a simple tool for analyzing Wine code. Currently
> it can do the following:
> - Find BOOL functions returning non-BOOL.
> - Find HRESULT functions returning non-HRESULTs.
> - Generate a TRACE() for each function showing all its parameters.
>
> It isn't really a formal C parser, as it ignores all preprocessor
> directives, but this makes it *much* simpler and shorter than a real C
> parser, and it sees original Windows types like LPCWSTR etc. It's not
> 100% accurate, but it's very effective. 3 of my recent patches have
> been generated with its help - and I've barely gotten started.
>
> I'd like to add the following features at some stage:
> - Populate all functions with a TRACE() of their arguments, if they
>
> don't already have it.
> - Scan all GUIDs in include/ and generate a full list of all GUIDs and
>
> their names. Then patch debugstr_guid() to also output the name of the
> GUID when available, and/or search and replace GUIDs in WINEDEBUG
> traces after they've been recorded.
> - Update .spec files from .c file contents, and verify .spec file accuracy.
> - It could be extended to examine contents of functions and enforce
>
> the absence of W->A and 32->16 calls, etc.
> - etc.

I'd say put it on github. Which language do you use? I have a hacked tool for one feature, maybe i'll clean it up and send a patch/git-pull-request.

[Damjan Jovanovic]

On Tue, Jan 15, 2013 at 9:06 PM, André Hentschel  wrote:
> Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
> > Hi
> >
> > I've hacked together a simple tool for analyzing Wine code. Currently
> > it can do the following:
> > - Find BOOL functions returning non-BOOL.
> > - Find HRESULT functions returning non-HRESULTs.
> > - Generate a TRACE() for each function showing all its parameters.
> >
> > It isn't really a formal C parser, as it ignores all preprocessor
> > directives, but this makes it *much* simpler and shorter than a real C
> > parser, and it sees original Windows types like LPCWSTR etc. It's not
> > 100% accurate, but it's very effective. 3 of my recent patches have
> > been generated with its help - and I've barely gotten started.
> >
> > I'd like to add the following features at some stage:
> > - Populate all functions with a TRACE() of their arguments, if they
> >
> > don't already have it.
> > - Scan all GUIDs in include/ and generate a full list of all GUIDs and
> >
> > their names. Then patch debugstr_guid() to also output the name of the
> > GUID when available, and/or search and replace GUIDs in WINEDEBUG
> > traces after they've been recorded.
> > - Update .spec files from .c file contents, and verify .spec file accuracy.
> > - It could be extended to examine contents of functions and enforce
> >
> > the absence of W->A and 32->16 calls, etc.
> > - etc.
>
> I'd say put it on github. Which language do you use? I have a hacked tool for one feature, maybe i'll clean it up and send a patch/git-pull-request.
>
> --
>
> Best Regards, André Hentschel

Java
svn co https://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery/GrapeVineScan...
mvn package

Then run it, eg.:
java -jar target/GrapeVineScanner-0.1-SNAPSHOT.jar checkHresultReturns
/path/to/wine/dlls/shell32/shlfileop.c

Function parse_file_list returns ERROR_INVALID_PARAMETER which might
not be a HRESULT
Function parse_file_list returns ERROR_ACCESS_DENIED which might not
be a HRESULT
Function copy_files returns ERROR_SHELL_INTERNAL_FILE_NOT_FOUND which
might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_SUCCESS which might not be a HRESULT
Function copy_files returns ERROR_NO_MORE_SEARCH_HANDLES which might
not be a HRESULT
Function copy_files returns ERROR_SUCCESS which might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_CANCELLED which might not be a HRESULT
Function copy_files returns ERROR_SUCCESS which might not be a HRESULT
Function delete_files returns ERROR_SUCCESS which might not be a HRESULT
Function delete_files returns 0 which isn't a HRESULT constant
Function delete_files returns ERROR_PATH_NOT_FOUND which might not be a HRESULT
Function delete_files returns ERROR_SUCCESS which might not be a HRESULT
Function move_files returns ERROR_CANCELLED which might not be a HRESULT
Function move_files returns ERROR_CANCELLED which might not be a HRESULT
Function move_files returns ERROR_CANCELLED which might not be a HRESULT
Function move_files returns ERROR_CANCELLED which might not be a HRESULT
Function move_files returns ERROR_CANCELLED which might not be a HRESULT
Function move_files returns ERROR_CANCELLED which might not be a HRESULT
Function move_files returns ERROR_SUCCESS which might not be a HRESULT
Function rename_files returns ERROR_GEN_FAILURE which might not be a HRESULT
Function rename_files returns ERROR_CANCELLED which might not be a HRESULT
Function rename_files returns ERROR_SHELL_INTERNAL_FILE_NOT_FOUND
which might not be a HRESULT
Function rename_files returns ERROR_ALREADY_EXISTS which might not be a HRESULT
Function rename_files returns SHNotifyMoveFileW(feFrom->szFullPath,
feTo->szFullPath) which might not be a HRESULT
Function SHPathPrepareForWriteA returns SHPathPrepareForWriteW(hwnd,
modless, wpath, flags) which might not be a HRESULT

[Damjan Jovanovic]

On Tue, Jan 15, 2013 at 9:15 PM, Damjan Jovanovic  wrote:
> On Tue, Jan 15, 2013 at 9:06 PM, André Hentschel  wrote:
> > Am 15.01.2013 18:51, schrieb Damjan Jovanovic:
> > > Hi
> > >
> > > I've hacked together a simple tool for analyzing Wine code. Currently
> > > it can do the following:
> > > - Find BOOL functions returning non-BOOL.
> > > - Find HRESULT functions returning non-HRESULTs.
> > > - Generate a TRACE() for each function showing all its parameters.
> > >
> > > It isn't really a formal C parser, as it ignores all preprocessor
> > > directives, but this makes it *much* simpler and shorter than a real C
> > > parser, and it sees original Windows types like LPCWSTR etc. It's not
> > > 100% accurate, but it's very effective. 3 of my recent patches have
> > > been generated with its help - and I've barely gotten started.
> > >
> > > I'd like to add the following features at some stage:
> > > - Populate all functions with a TRACE() of their arguments, if they
> > >
> > > don't already have it.
> > > - Scan all GUIDs in include/ and generate a full list of all GUIDs and
> > >
> > > their names. Then patch debugstr_guid() to also output the name of the
> > > GUID when available, and/or search and replace GUIDs in WINEDEBUG
> > > traces after they've been recorded.
> > > - Update .spec files from .c file contents, and verify .spec file accuracy.
> > > - It could be extended to examine contents of functions and enforce
> > >
> > > the absence of W->A and 32->16 calls, etc.
> > > - etc.
> >
> > I'd say put it on github. Which language do you use? I have a hacked tool for one feature, maybe i'll clean it up and send a patch/git-pull-request.
> >
> > --
> >
> > Best Regards, André Hentschel
>
> Java
> svn co https://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery/GrapeVineScan...
> mvn package

Or rather:
svn co https://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery
cd RaisingRefinery
mvn package
java -jar GrapeVineScanner/target/GrapeVineScanner-0.1-SNAPSHOT.jar
checkHresultReturns /path/to/wine/dlls/shell32/shlfileop.c