On Thu, Feb 20, 2014 at 7:42 AM, Jonathan Wakely <jwakely....@gmail.com> wrote:
> On 20 February 2014 10:02, Patrick Palka <patr...@parcs.ath.cx> wrote:
>> On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely <jwakely....@gmail.com>
>> wrote:
>>> On 13 February 2014 20:47, Patrick Palka wrote:
>>>> On a related note, would a patch to officially enable
>>>> -Wmissing-declarations in the build process be well regarded?
>>>
>>> What would be the advantage?
>>
>> A missing declaration for an extern function definition likely means
>> that the function should be marked static instead, so enabling the
>> flag would help detect whether a function should otherwise be given
>> static linkage. Isn't this especially important in libstdc++, where
>> accidentally exposing an internal symbol in the library's ABI means
>> having to keep the symbol around until the next ABI bump?
>
> It's not really an issue for libstdc++. All symbols are internal by
> default and we only export specifically chosen symbols. If a new
> symbol accidentally matches an existing pattern in the linker script
> then it will be noticed by the testsuite ('make check-abi' in the
> $objdir/$target/libstdc++-v3 dir) and we will make the pattern more
> specific.
Ah, ok, that makes sense.
>
> Making some functions static might be worthwhile, but for the other
> ones referred to in this quote from your first email:
>
>> The rest of the
>> fixes are on global function definitions whose declaration exists in a
>> header file that was not included by the source file. To fix up these
>> functions I simply included the relevant header file.
>
> The only advantage of this change is that if the definition is changed
> without also changing the header then you might get a failure during
> compilation rather than linking, but even that isn't guaranteed as the
> new definition could be interpreted as an overload rather than an
> incompatible declaration.
Wouldn't the overload require a separate declaration, which would be
missing, and thus the compiler would still emit the warning?
>
> Otherwise, including the header isn't *wrong* but it doesn't really
> gain much, except silencing a warning, and that warning is only
> emitted because you turned it on :-) And as you also said, some files
> can't easily be fixed to avoid the warning. IMHO the simplest way to
> solve the problem is not turn the warnings on!
For what it's worth, I have fixed the files that I originally regarded
as not easily fixable. They were pretty easy to fix after a little
bit of thought.
>
> Maybe others will disagree and will think enabling
> -Wmissing-declarations would be a useful change, but I don't see the
> point.
In my novice opinion, I think the flag helps keep source files tidy
and modular, and their interfaces well-defined. Its biggest benefit
is having the compiler inform you when a function should have been
marked static: marking a function static facilitates better
optimization and static analysis, and it helps convey the intent of
the function to the reader. (I counted nearly 100 (non-debug)
functions that could be made static in gcc, and 4 in libstdc++, by the
way.)
