bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: msvc-inval: more options


From: Jim Meyering
Subject: Re: msvc-inval: more options
Date: Wed, 28 Sep 2011 09:34:54 +0200

Bruno Haible wrote:
>> FAIL: test-fgetc.exe
>> FAIL: test-fputc.exe
>> FAIL: test-fread.exe
>> FAIL: test-fwrite.exe
>>
>> All these fail on a stream whose file descriptor has been closed. Most
>> libraries won't do such a thing. Therefore I don't find it worth to fix
>> this. Just document it.
>
> But two of the tests still fail, and the other two succeed only accidentally.
> This patch makes the 4 tests pass:

Hi Bruno,

I noticed that the latest from gnulib's tests gets some new warnings
when compiled on Fedora 15:

    test-fread.c: In function 'main':
    test-fread.c:43:3: error: implicit declaration of function 
'gl_msvc_inval_ensure_handler' [-Werror=implicit-function-declaration]
    cc1: all warnings being treated as errors

    test-fputc.c: In function 'main':
    test-fputc.c:43:3: error: implicit declaration of function 
'gl_msvc_inval_ensure_handler' [-Werror=implicit-function-declaration]
    cc1: all warnings being treated as errors

    test-fwrite.c: In function 'main':
    test-fwrite.c:43:3: error: implicit declaration of function 
'gl_msvc_inval_ensure_handler' [-Werror=implicit-function-declaration]
    cc1: all warnings being treated as errors

    make[3]: *** [test-fputc.o] Error 1
    make[3]: *** Waiting for unfinished jobs....
    make[3]: *** [test-fread.o] Error 1
    make[3]: *** [test-fwrite.o] Error 1
      CC       test-strings.o
    test-fgetc.c: In function 'main':
    test-fgetc.c:43:3: error: implicit declaration of function 
'gl_msvc_inval_ensure_handler' [-Werror=implicit-function-declaration]
    cc1: all warnings being treated as errors

That's because the guard in each test-*.c file is weaker
than the guards in msvc-inval.h.  Thus, the use is exposed
while the declaration is not.

>From msvc-inval.h:

    #define DEFAULT_HANDLING       0
    #define HAIRY_LIBRARY_HANDLING 1
    #define SANE_LIBRARY_HANDLING  2

    #if HAVE_MSVC_INVALID_PARAMETER_HANDLER \
        && !(MSVC_INVALID_PARAMETER_HANDLING == SANE_LIBRARY_HANDLING)
    /* A native Windows platform with the "invalid parameter handler" concept,
       and either DEFAULT_HANDLING or HAIRY_LIBRARY_HANDLING.  */

    # if MSVC_INVALID_PARAMETER_HANDLING == DEFAULT_HANDLING
    /* Default handling.  */

    #  ifdef __cplusplus
    extern "C" {
    #  endif

    /* Ensure that the invalid parameter handler in installed that just returns.
       Because we assume no other part of the program installs a different
       invalid parameter handler, this solution is multithread-safe.  */
    extern void gl_msvc_inval_ensure_handler (void);

    #  ifdef __cplusplus
    }
    #  endif

>From test-fread.c:

    #if MSVC_INVALID_PARAMETER_HANDLING == DEFAULT_HANDLING
      gl_msvc_inval_ensure_handler ();
    #endif

To kludge around it, I built with this:

    make check CFLAGS=-DMSVC_INVALID_PARAMETER_HANDLING=99

Wouldn't it be better to make the commonly-used-in-application-code
      gl_msvc_inval_ensure_handler ();
a no-op when possible, so that applications don't need to guard
uses of it with #if directives like those above?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]