[Numpy-discussion] Toward a numpy build with warning: handling unused variable

[Lisandro Dalcin]

David, I second your approach. Furthermore, look how SWIG handles
this, it is very similar to your proposal. The difference is that SWIG
uses SWIGUNUSED for some autogenerated functions. Furthermore, it
seems the SWIG developers protected the generated code taking into
account GCC versions ;-) and the C++ case, and also Intel compilers.

/* attribute recognised by some compilers to avoid 'unused' warnings */
#ifndef SWIGUNUSED
# if defined(__GNUC__)
#   if !(defined(__cplusplus)) || (__GNUC__ > 3 || (__GNUC__ == 3 &&
__GNUC_MINOR__ >= 4))
#     define SWIGUNUSED __attribute__ ((__unused__))
#   else
#     define SWIGUNUSED
#   endif
# elif defined(__ICC)
#   define SWIGUNUSED __attribute__ ((__unused__))
# else
#   define SWIGUNUSED
# endif
#endif

#ifndef SWIGUNUSEDPARM
# ifdef __cplusplus
#   define SWIGUNUSEDPARM(p)
# else
#   define SWIGUNUSEDPARM(p) p SWIGUNUSED
# endif
#endif


On Sun, Aug 3, 2008 at 10:39 PM, David Cournapeau
<cournapeau at cslab.kecl.ntt.co.jp> wrote:
> On Sun, 2008-08-03 at 19:32 -0500, Charles R Harris wrote:
>
>>
>>
>>
>> There is self and args, filter them out. If the arguments have other
>> names, rename them.
>
> That's much more error prone. You would need a list of such arguments,
> and more importantly, it means you cannot enable warning by default
> (because you cannot expect the casual user to filter them out).
>
> And if you filter them out, you won't see them, meaning you hide them
> anyway. So I don't really see the point.
>
>>
>>
>>         > If the warnings are too
>>         > numerous, filter them.
>>
>>
>>         If you filter them, what's the point of keeping them ?
>>
>>
>>
>> Because the compiler's inadequate determination of errors is driving
>> the coding.
>
> I don't understand what you mean here ? The problem I see is the
> following: currently, there are so many warnings that we don't enable
> them, and I would guess nobody currently enable them.
>
>> That seems wrong way around. Maybe these variables can be notated
>> somehow, i.e, __unused__(arg), which would at least document intent.
>
> Which is what I have been arguing all along :) If you look at the link I
> posted before, it suggests a UNUSED macro which uses gcc attribute when
> build with gcc, and do nothing otherwise:
>
> #ifdef __GNUCC__
> #define NPY_UNUSED(x) NPY_UNUSED__ ## x __attribute__((unused))
> __NPY_MANGLE_UNUSED)
> #else
> #define NPY_UNUSED(x) x
> #endif
>
> This makes it hard to get it wrong:
>  - you can't use the variable by accident later: you will get a
> compilation error thanks to the mangling
>  - you don't have meaningless warnings, meaning you see the real ones.
>  - if you don't use gcc, it is exactly as before.
>
> I realize I may have not been not really clear: I am not suggesting to
> remove any warning about unused variable, just the ones which we cannot
> do anything about because they are in the argument list and we know for
> sure we will not use them. That include python C functions not used as a
> method (dummy/unused, e.g. the first argument), ufunc which do not use
> their func argument, etc...
>
> cheers,
>
> David
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594