This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Add forward declarations
On Mon, Oct 1, 2018 at 9:04 PM, Craig Howland <howland@lgsinnovations.com>
wrote:
> On 10/01/2018 05:37 PM, Christophe Lyon wrote:
>
>> Hi,
>>
>> While building newlib for Aarch64, I noticed several warnings because
>> of missing prototypes. I am not familiar enough to know why the same
>> warnings do not appear when building for Arm.
>>
>> This patch adds the missing prototypes, tested by rebuilding for
>> Aarch64 and Arm, it removed the warnings and didn't generate any
>> error.
>>
>> OK?
>>
>> Christophe
>>
> A primary reason for prototypes is that they are for checking, and
> fully-proper checking is a single header file that checks both the source
> providing the function as well as places that call the function. That is,
> adding prototypes in the function definition file purely for the purposes
> of avoiding missing prototype warnings is missing the real usefulness
> behind the warning and giving a false sense of security. (You'd be better
> off just taking -Wmissing-prototypes out of your options to avoid those
> particular warnings.) The prototypes need to be added to a header file,
> not the functions' own source.
>
> Put another way, as a general goal I'd think we ought to be fixing the
> cause of a warning to remove the warning, rather than doing things to
> "hide" or "mask" the warning (which could be considered as kludges).
> Putting protoypes into the function source file is clearly masking the
> deficiency that there is not a header file with prototypes, rather than
> fixing the actual deficiency. While there certainly are times when
> addressing the root cause of a warning is not possible, this does not seem
> to be one where it is appropriate. Probably something like sys/_syscall.h
> (or some such name) should be created and used. We should be cleaning up
> bad practice when it exists, not furthering it. So, definitely a good
> thing to get rid of the warnings, but there is a much better approach to
> take in this case.
>
> Corrina or Jeff, any suggestions for a good place for syscall prototypes?
> (My first thought was sys/syscalls.h, but the Linux syscall(2) manpage
> mentions that related to syscall() and "For SYS_xxx definitions." Perhaps
> it would be OK, but perhaps not, too, which is why I ended up suggesting
> _syscall.h.) Does someone know about a precedent in BSD or the like?
>
My suggestion is to set the _COMPILING_NEWLIB flag in configure.host for
aarch64 as is already done for arm-*-*.
-- Jeff J.
> Craig
>