[Jeff Morriss <jeff.morriss@xxxxxxxxxxx>]

Peter Johansson wrote:
> 2007/3/30, Jeff Morriss <jeff.morriss@xxxxxxxxxxx 
[...]
> After having read the description for bug 1377 I agree. This patch fixes 
> that problem.
>
> err_str should not be allocated prior to calling 
> get_airpcap_interface_list(&err, &err_str). err_str gets assigned a 
> pointer to allocated memory (g_strdup) in the called function that gets 
> freed when returning from the function.
>
> Thank you for having me review my changes once more. It turns out that 
> my original change will make the code call g_free for the newly added 
> statically allocated error description which would be a new error.
> I have attached a new set of files to be supplied as a solution for bug 
> 1377. This time my changes allocate the error description using g_strdup 
> just like the rest of the code, making it possible to call g_free upon 
> return from the get_airpcap_interface_list(...) function.
>
> I was also wondering how to handle this case, should it not produce a 
> dialogue at all? I am unsure. If a dialogue is not displayed, the user 
> will never understand why the AirPcap devices do not show up if AirPcap 
> is not loaded but Wireshark is compiled with support for it. On the 
> other hand, I guess most users do not have AirPcap, which means that it 
> would be annoying to get the dialogue every time when entering the 
> options dialogue.

It appears from the rest of the code that the intention is NOT to pop up 
a dialog in this case (since it specifically checks to see if no 
interfaces are found).  The problem was if AirPcap is not loaded at all 
then the error value is uninitialized so it could be 1--in which case 
the dialog is popped up but with bogus contents.

Fixed in rev 21380 by simply setting the error value to a new value 
(AIRPCAP_NOT_LOADED) so the caller knows not to pop up the dialog.

Presumably someone with airpcap.dll has to find out by some other means 
that it's not being loaded properly.