This was changed from a unsigned int to a pointer in e5d37832ee66d011ba572a9b571e9fb44a7b2b4d and this use was missed, causing prefix creation hang if the allocated printers array is not filled with zeros.
Signed-off-by: Rémi Bernon rbernon@codeweavers.com ---
I'm also not sure to see why this was changed to a pointer, imho it's a little more ugly than the integer, which would simply have to be mapped on output for wow64 too and would have required less changes overall? But maybe there was a specific reason?
dlls/winspool.drv/info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c index 3424c69d196..ac8f0994a1c 100644 --- a/dlls/winspool.drv/info.c +++ b/dlls/winspool.drv/info.c @@ -800,7 +800,7 @@ static BOOL init_unix_printers( void ) if (printer->is_default) default_printer = printer->name; }
- if (!default_printer && enum_params.num) default_printer = enum_params.printers[0].name; + if (!default_printer && num) default_printer = enum_params.printers[0].name; if (default_printer) SetDefaultPrinterW( default_printer );
if (ppd_dir)
Rémi Bernon rbernon@codeweavers.com writes:
This was changed from a unsigned int to a pointer in e5d37832ee66d011ba572a9b571e9fb44a7b2b4d and this use was missed, causing prefix creation hang if the allocated printers array is not filled with zeros.
Signed-off-by: Rémi Bernon rbernon@codeweavers.com
I'm also not sure to see why this was changed to a pointer, imho it's a little more ugly than the integer, which would simply have to be mapped on output for wow64 too and would have required less changes overall? But maybe there was a specific reason?
In general, I think it's better to use parameter structs the same way as standard function parameters. It avoids having to remember to unmap them in the wow64 thunks, and it should make it possible later on to optimize them using standard parameter passing.