Could I obtain the forms needed to make a contribution?

Moritz Strübe
Sun Jan 5 15:34:00 GMT 2020


you can use Dmitry's solution at compile-time, too. "-D__LINE__={int 
This will most likely trigger an parse-error, because an int is 
expected. And if the code does parse, it will fail at the array-length 
being -1. You'll still might need to turn off some warning, because you 
are overriding a compiler-macro.


*I'm sure there are even better ways to trigger a compile time error, 
but this is what I came up with as a non-expert without having to think 
too much about corner cases. ;)

Am 04.01.2020 um 03:23 schrieb Eric Curtin:
> Hi Guys,
> Sorry I switched off the email for the holidays.
> I guess the problem with the linker error is, we have a distributed
> build system with the linking occurring at the very end of the build
> (we have a slow build, that's a different problem though).
> So it's compile time that this would be preferable like -Wdate-time
> does. Would introducing a new warning be the only way to achieve this?
> Other than the clever linker way below?
> On 19/12/2019, Dmitry Grinberg <> wrote:
>> Why not just add "-D__LINE__=LinkerError_LineMacroUsed_DoNotDoThat()" to
>> ----
>> Best Regards,
>> Dmitry Grinberg
>> On Mon, Dec 16, 2019 at 3:51 AM Eric Curtin <> wrote:
>>> I want to add a compiler warning, if it will get accepted. It's a
>>> -Wlines warning. My employer bans the __LINE__ macro as well as the
>>> ones warned by the -Wdate-time warning, because there is a consensus
>>> that the addition of whitespace or comments should not yield different
>>> binary output for our project. Would this patch get accepted?

Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: | Web:

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843

More information about the Gcc mailing list