Recent clang versions warn if an include file changes the pragma pack level without restoring it before the end of the include file.
This avoids warnings for each include of pshpack*.h/poppack.h.
Signed-off-by: Martin Storsjo martin@martin.st --- configure.ac | 1 + 1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac index 25d88d8..018b122 100644 --- a/configure.ac +++ b/configure.ac @@ -1853,6 +1853,7 @@ then WINE_TRY_CFLAGS([-Wempty-body]) WINE_TRY_CFLAGS([-Wignored-qualifiers]) WINE_TRY_CFLAGS([-Wno-packed-not-aligned]) + WINE_TRY_CFLAGS([-Wno-pragma-pack]) WINE_TRY_CFLAGS([-Wshift-overflow=2]) WINE_TRY_CFLAGS([-Wstrict-prototypes]) WINE_TRY_CFLAGS([-Wtype-limits])
On 2018-01-21 23:05, Martin Storsjo wrote:
Recent clang versions warn if an include file changes the pragma pack level without restoring it before the end of the include file.
This avoids warnings for each include of pshpack*.h/poppack.h.
Do you think a #pragma clang diagnostic inside those headers would be feasible, to avoid hiding true positive instances of this warning?
Best, Thomas
On Mon, 22 Jan 2018, Thomas Faber wrote:
On 2018-01-21 23:05, Martin Storsjo wrote:
Recent clang versions warn if an include file changes the pragma pack level without restoring it before the end of the include file.
This avoids warnings for each include of pshpack*.h/poppack.h.
Do you think a #pragma clang diagnostic inside those headers would be feasible, to avoid hiding true positive instances of this warning?
That might be a good idea - I can try looking into that.
// Martin
On Mon, 22 Jan 2018, Thomas Faber wrote:
On 2018-01-21 23:05, Martin Storsjo wrote:
Recent clang versions warn if an include file changes the pragma pack level without restoring it before the end of the include file.
This avoids warnings for each include of pshpack*.h/poppack.h.
Do you think a #pragma clang diagnostic inside those headers would be feasible, to avoid hiding true positive instances of this warning?
I tested this now. It's easy to get rid of the warnings from the pshpack*.h files (by e.g. #pragma clang diagnostic push, #pragma clang diagnostic ignored "-Wpragma-pack").
Bbut if I do "#pragma clang diagnostic pop" within poppack.h, the warning is enabled again once the end of poppack.h is reached, and the warning gets triggered at the end of the source file. So each pair of pshpack*.h/poppack.h would need disabling the warning ignoring again after the #include "poppack.h".
Do you have any suggestions on how to handle that better, or is it just simplest to go for the blanket ignore?
// Martin
On 2018-01-22 22:42, Martin Storsjö wrote:
This avoids warnings for each include of pshpack*.h/poppack.h.
Do you think a #pragma clang diagnostic inside those headers would be feasible, to avoid hiding true positive instances of this warning?
I tested this now. It's easy to get rid of the warnings from the pshpack*.h files (by e.g. #pragma clang diagnostic push, #pragma clang diagnostic ignored "-Wpragma-pack").
Bbut if I do "#pragma clang diagnostic pop" within poppack.h, the warning is enabled again once the end of poppack.h is reached, and the warning gets triggered at the end of the source file. So each pair of pshpack*.h/poppack.h would need disabling the warning ignoring again after the #include "poppack.h".
Do you have any suggestions on how to handle that better, or is it just simplest to go for the blanket ignore?
Thanks for trying it out. That's pretty much what I feared. Sounds like this warning is broken by design then, so the blanket disable seems right to me.
On Tue, 23 Jan 2018, Thomas Faber wrote:
On 2018-01-22 22:42, Martin Storsjö wrote:
This avoids warnings for each include of pshpack*.h/poppack.h.
Do you think a #pragma clang diagnostic inside those headers would be feasible, to avoid hiding true positive instances of this warning?
I tested this now. It's easy to get rid of the warnings from the pshpack*.h files (by e.g. #pragma clang diagnostic push, #pragma clang diagnostic ignored "-Wpragma-pack").
Bbut if I do "#pragma clang diagnostic pop" within poppack.h, the warning is enabled again once the end of poppack.h is reached, and the warning gets triggered at the end of the source file. So each pair of pshpack*.h/poppack.h would need disabling the warning ignoring again after the #include "poppack.h".
Do you have any suggestions on how to handle that better, or is it just simplest to go for the blanket ignore?
Thanks for trying it out. That's pretty much what I feared. Sounds like this warning is broken by design then, so the blanket disable seems right to me.
Yeah - the other alternative I can think of is splitting poppack.h into two; one poppack-internal.h that does the actual pragma pack pop, and the outer one that resets the warning again. But that's again a little too much effort for this warning.
// Martin
-
Martin Storsjo -
Thomas Faber