Sorry, I didn’t have much context for the original issue and was probably too
terse in my responses. Some more elaboration inline below.
> On Jan 13, 2020, at 01:14, Andreas Tille <andr...@fam-tille.de> wrote:
>
> On Sun, Jan 12, 2020 at 02:08:56PM -0800, Matthew Fernandez wrote:
>>
>>> On Jan 12, 2020, at 12:49, Andreas Tille <andr...@an3as.eu> wrote:
>>>
>>> Hi,
>>>
>>> I'm wondering how this bug
>>>
>>>
>>> rk1968/rk1968.cc: In lambda function:
>>> rk1968/rk1968.cc:237:103: error: expected '{' before '->' token
>>> 237 | auto make_error_return = [&L] ( const char* fmt, ...)
>>> __attribute__ ((format (printf, 2, 3))) -> int
>>> |
>>> ^~
>>>
>>>
>>> with gcc 9 can be fixed in aghermann. Any help would be appreciated.
>>
>> Turning this into a C++11 attribute ([[gnu::format(printf, 2, 3)]]) makes
>> the parse error go away, but -Wattributes still indicates GCC is ignoring it.
>
> I admit I do not understand your "but -Wattributes ...". I can confirm
> that this patch[1] builds the package successfully.
-Wattributes is a flag to GCC to enable warnings about attributes. What I did
to experiment was extract the code you’d quoted into an isolated context:
$ cat - >test.cc <http://test.cc/> <<EOT
void foo(int L) {
auto make_error_return = [&L] ( const char* fmt, ...) __attribute__
((format (printf, 2, 3))) -> int
{
return 0;
}
}
EOT
$ g++ -std=c++11 -c -Wattributes test.cc
>> You might need to bump that GCC issue with some evidence that the bug still
>> exists and see what the maintainers say.
>
> 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/>
