[libvirt] [PATCH 13/15] util: Replace pciWaitForDeviceCleanup with a stub on Windows

[Matthias Bolte]

2010/3/22 Daniel P. Berrange <berrange at redhat.com>:
> On Mon, Mar 22, 2010 at 10:54:09AM -0600, Eric Blake wrote:
>> On 03/22/2010 09:03 AM, Daniel P. Berrange wrote:
>> > On Mon, Mar 22, 2010 at 02:25:43AM +0100, Matthias Bolte wrote:
>> >> sscanf doesn't support the L modifier on Windows and gnulib has no
>> >> replacement for the scanf functions. Just replace the function with
>> >> a stub on Windows, because it's not used on the libvirt client side.
>> >> ---
>> >>  src/util/pci.c |   14 ++++++++++++++
>> >>  1 files changed, 14 insertions(+), 0 deletions(-)
>> >
>> > We already had this problem with printf(). For that gnulib provided
>> > us with a replacement that worked. We should probably pull in the
>> > scanf module from gnulib for equivalent compatability. Even though
>> > this code isn't technically required, other places may start using
>> > scanf & trip up on this problem
>>
>> But that's the point that Matthias made - currently, gnulib does NOT
>> provide a scanf module.  Why?  Because scanf comes with its own set of
>> usability pitfalls (scanf("%d",&int) cannot report whether integer
>> overflow occurred), so no one has made it a high enough priority to
>> start replacing the portability pitfalls.
>
> Oh, I mis-read the original description!
>
>> I've already mentioned that it would be a better cleanup to stop using
>> *scanf altogether; but that would be an independent cleanup, unrelated
>> to this particular patch.
>>
>> For this particular patch, mingw also lacks /proc/iomem, so the fopen
>> earlier in pciWaitForDeviceCleanup should have already failed before we
>> ever get to the problematic sscanf("%Lx").  Therefore, do we even need
>> this patch?
>
> I don't think its high priority to merge this, since its not an actual
> compile failure - I agree we'd be better to just kill off the use of
> scanf() altogether
>
>
> Daniel
>

Well, MinGW's GCC on Windows warns about the L modifier being unknown.
So this patch was about the compile warning and not about an actual
runtime error. I should have said that more clearly.

I withdraw this patch, as it's superseded by the scanf/atoi removal
patches I just posted. The next part of that series will also address
the usage of the unportable %as field in a scanf call in the ESX
driver that results in an runtime error on Windows.

Matthias