Fix nasty malloc/free bug when setting a printer attribute with a zero length (Lexmark

drivers do this). tdb_unpack() on case 'B' was leaving the data pointer uninitialized.
This seemed OK (but bad practice) for a zero lenght buffer, but many cycles later
free_nt_printer_param() did a safe_free on the uninitialized pointer. This affected
both APPLIANCE_HEAD and 2.2 (HEAD too I expect).

2.2 only was hit by a differert aspect of the situation above. When a zero len attribute
is processed by api_spoolss_setprinterdata(), talloc (in non DEBUG_TALLOC), returns NULL
up the chain and "unable to unmarshall SPOOL_Q_SETPRINTERDATA" occurs.

JohnR

0 files changed, 0 insertions, 0 deletions