This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add forward declarations


On Tue, 2 Oct 2018 at 17:31, Jeff Johnston <jjohnstn@redhat.com> wrote:
>
> 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-*-*.
>

OK, thanks for the suggestion, it works. Is this new patch OK?


> -- Jeff J.
>
>
> > Craig
> >

Attachment: newlib-5.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]