Thanks a lot for the very helpful comments, Andreas. On Mon, Jan 13, 2020 at 07:20:24AM -0800, Matthew Fernandez wrote: > > I need to admit that I understand so less from all the gcc issues you > > tried to explain - I do not even have any idea what C++ attributes are. > > I simply cared for that Debian bug since nobody else did. :-( > > So I feel really incompetent to discuss this with gcc maintainers but > > I'd welcome if you bring it up there. > > GCC attributes like the __attribute__ example here are a mechanism for > annotating C/C++ code with things not covered by the ISO standards, but > supported by compiler extensions. Attributes can be applied to many things > including variables and functions, and the function attributes are documented > at https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html > <https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. These days > Clang also understands many of the GCC attributes. > > The particular one in question here is telling the compiler that the lambda > function being defined has similar behavior to the libc printf function. The > integer parameters say a printf format string appears as the second argument > and the first varargs parameter is the third argument. This looks off by one, > but I think the captured local (&L) counts as the first parameter. The only > thing the compiler uses this attribute for is to detect calls to this lambda > with incorrect arguments and emit warnings for them. > > The C++11 standard brought in a more commonly supported way of declaring > attributes using square brackets. Unfortunately the standard does not support > many common attributes and you still need to use a “gnu::” prefix to access > the GCC-specific attributes. Hence, “[[gnu::format(printf, 2, 3)]]” being the > C++11 equivalent of this. > > >> If you need to bypass this urgently, I would recommend deleting the > >> attribute as that particular one is only used to aid the compiler in > >> creating warnings. > > > > Hmmm, as I said my patch[1] works and I just have the gut feeling (as I > > said I have no competence!) that this might be better than to delete the > > attribute. If not would you mind sending an alternative patch which is > > better in your opinion? > > Lambda functions, which are already being used in this code, are a C++11 > feature as are this style of attributes. So I imagine it would be acceptable > to upstream to take your patch. Having said that, when I did this in my > experiment code above the compiler warned that it was ignoring this attribute > as it thought it was being applied to the trailing “int”. > > I re-read the GCC issue and realized I’d misread Jonathan Wakely’s comments. > The issue is actually still open and Jonathan was just noting that r265787 > introduced the bug, not fixed it. So I think what we’re seeing is consistent > with the GCC maintainers’ view. > > I would suggest proposing your patch upstream. Although its primary purpose > is working around a compiler bug, it’s also an objective improvement in > modernizing the code base. > > > Thanks again > > > > Andreas. > > > > > >> [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 > >> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333> > > > > [1] > > https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch > > > > <https://salsa.debian.org/med-team/aghermann/blob/master/debian/patches/workaround_gcc-9_issue.patch> > > > > -- > > http://fam-tille.de <http://fam-tille.de/>
> _______________________________________________ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
