Hi,

>     > Change calls to open() to call ws_open(), instead, so that, on
>     Windows, they can handle UTF-8 pathnames (by turning them into
>     UTF-16 pathnames and passing them to routines that take UTF-16
>     pathnames, rather than using various code page encodings for strings).
>     >
>     > Also use ws_close() instead of close().  (The ws_ calls, on
>     Windows, also call the Visual Studio C library routines that
>     implement UN*X-style APIs, with an underscore preceding the UN*X API
>     name.)
> 
>     Thank you for explanation and I understand the reasons, but I don't
>     think it is possible in this case. Classes extending QIODevice where
>     open/close are parent methods I must call/override.
>     It looks that it is false positive check. Is there any way how to add
>     exception to check in this case?
> 
> THere is already some code in checkAPIs.pl file to identify false positives:
> 
>                 # Match function calls, but ignore false positives from:
>                 # C++ method definition: int MyClass::open(...)
>                 # Method invocation: myClass->open(...);
>                 # Function declaration: int open(...);
>                 # Method invocation: QString().sprintf(...)
>                 while (${$fileContentsRef} =~ m/ \W (?<!::|->|\w\ )
> (?<!\.) $api \W* \( /gx)
>                 {
>                         $cnt += 1;
>                 }
>                 if ($cnt > 0) {
>                         push @{$foundAPIsRef}, $api;
>                         $groupHashRef->{function_counts}->{$api} += 1;
>                 }
> 
> This probably needs to be improved for your use case.

The solution was to fully clasify parent's methods. E.g. open() to
QIODevice::open(). This is already checked in checkAPIs.pl and it solved
the issue.

Thank you all for help.

                                                Best regards,

                                                        Jirka Novak

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to