On Sun, 14 Aug 2016, dw wrote:
>>> - _vswprintf_p.c, _vscwprintf_p.c - these also add a comment that wasn't
>>> there before. Probably ok, but I guess it's preferrable to have such
>>> changes split out.
>>> - aviriff.h, I see no other changes than adding in leading zeros
>
> Yes, that's true. However, there is another header that *doesn't* have
> those zeros. So while from a functional point of view it makes
> absolutely no difference, the compiler warns about the "redefinition."
> Even a difference in spacing triggers this warning.
Ah, right, that was the missing explanation - now it makes more sense.
> In my mind, the "issue" I was resolving was "cleaning up warnings."
> Every line in this patch was designed with that goal (well, with the
> exception of the copyright. That's just habit). I didn't set out to
> "fix redefine errors," then "fix unreferenced parameter errors," etc.
> So in the end, I just have a bunch of files with fixes.
Yes, but from a reviewer perspective, or for someone digging through the
history later, it's much easier to handle with one patch per issue group.
> but 30 of these would be a huge hassle for the approvers as well.
Not really, if they are well contained with an explanation matching it
close by, it's trivial to review.
> ============= Missing prototypes =============
> clog10.c, clog10f.c, clog10l.c:
> - The prototypes for the functions created in these files are
> protected by #ifdef _GNU_SOURCE. Since we should always build
> the .c file, we need to add the define so we can find the
> prototype.
> gai_strerrorA.c:
> - wcstombs() is in stdlib.
> abs64.c:
> - llabs() is in stdlib.h.
> _vscprintf_p.c, _vscwprintf_p.c, _vswprintf_p.c:
> - _vscprintf_p_l, _vscwprintf_p_l & _vswprintf_p_l prototypes are
> protected by #if. Add the define so we can find them.
Sure
> ============= #define mismatches =============
> gs_support.c:
> - The minor variation causes a 'redefines' error.
> cephes_emath.h:
> - The minor variations cause 'redefines' errors.
> uchar.h:
> - __STDC_UTF_16__ & __STDC_UTF_32__ are defined by the gcc
> compiler.
I'd say split this one separately.
> dxgi.h:
> - Cheap way to avoid 'redefine' errors.
> aviriff.h, basetyps.h, combaseapi.h, gpedit.h:
> - Redefine errors.
> mfapi.h:
> - Redefine errors.
> mfidl.h:
> - Redefine errors.
> ntdef.h:
> - Redefine errors.
> ntsecapi.h:
> - These redefine values that are unconditionally defined earlier
> in the same file.
This one probably should go separately as well.
This way, one patch is for all the "adjust definitions in separate headers
to match, to avoid warnings about redefinition", and other patches for
other solutions.
> winnt.h:
> - Redefine errors.
>
> ============= Unreferenced variables =============
> gs_support.c:
> - ARM does not use StackCookie. I'd like to use the already-
> defined __UNUSED_PARAM from _mingw.h, but it uses an attribute,
> so I'd have to put it on the function declaration, and then I'd
> have to #ifdef it by platform. Yuck.
> ftw.c:
> - Unused parameters.
Sure
> ============= Add Pragma Diagnostic =============
> tdelete.c:
> - Comparing NULL to function pointer generates warning.
> stdio.h:
> - We are shadowing a number of functions provided by the compiler
> (snprintf, vsnprintf, etc). Ignore warnings.
> mfapi.h:
> - FCC ('AI44') et al cause 'multichar' compiler warnings. Ignore
> them.
>
> ============= Misc warnings =============
> e_pow.c:
> - Sign mismatch in comparison.
> mingw_pformat.c:
> - ARM does not support __attribute__((gcc_struct))
It's still not ARM that doesn't support it, it's clang.
> mingw_vfscanf.c:
> - Fix incorrect indention.
> mftransform.h:
> - EXTERN_C is either defined as 'extern' or 'extern "C"'. However,
> this isn't really an extern (implying that the actual definition
> is elsewhere), since the code also initializes the variable. And
> we don't need 'extern "C"' since this entire section is already
> wrapped with one. Using both 'extern' and initializing generates
> a warning.
I'd rather split these misc ones up to individual patches as well.
// Martin
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
