On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett <kbarr...@openjdk.org> wrote:
>>> I consider the "format '%p' expects argument of type 'void*" warnings to be >>> not at all helpful. Fortunately we don't use '%p' in HotSpot, >> >> We do use it in hotspot. Not a huge amount as we have the legacy format >> specifiers for PTR_FORMAT etc. > >> > I consider the "format '%p' expects argument of type 'void*" warnings to >> > be not at all helpful. Fortunately we don't use '%p' in HotSpot, >> >> We do use it in hotspot. Not a huge amount as we have the legacy format >> specifiers for PTR_FORMAT etc. > > You are correct, we do use "%p" a fair amount (107 lines today). > > I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and > the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are > to provide consistent output across platforms. "%p" provides implementation > defined output. For example, if I remember correctly, gcc "%p" prints "(null)" > for nullptr, with no mechanism (such as a conversion flag) to control that. If > you are printing a table of pointers, and you expect only numeric values > because you are going to be processing the table or copying it into a > spreadsheet or the like, that gcc-specific behavior isn't very helpful. > > Instead, we're "supposed" to use the `p2i` function and PTR_FORMAT for > printing pointers, to get the same output on all platforms. That idiom also > avoids the not very helpful -Wpedantic warnings. > > @kimbarrett quoting the gcc maintainers > > > Yes because the C++ defect report was only for `Spurious semicolons at > > > namespace scope should be allowed`. See > > > https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#569 . > > > ``` > > > struct f > > > { > > > int t; ; > > > }; > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is not allowed by the C++ standard currently and is a GCC extension, > > > maybe it should have a seperate flag to control that but I am not 100% > > > sure. > > That's incorrect, and I've replied in the gcc bug. C++14 added > "empty-declaration" to "member-declaration" (C++ 9.2). With my additional information the gcc bug has now been confirmed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927299264