why is a library function calling printf()? (if a c file needs something #include it).
On Tue, 18 Jun 2019 at 11:55, D. Hugh Redelmeier <[email protected]> wrote: > > Sorry, I was addressing this subject before I read this message. > > On Tue, 18 Jun 2019, Antony Antony wrote: > > | From: Antony Antony <[email protected]> > > | A while ago, while many of you were busy pushing 3.28 release an annoying > | warning/error crept in, travis test reported it only on CentOS 6. As I > | recollect, it was discarded as not important on IRC. I thought I will drop > | an e-mail about it. > > Yeah. We're good at ignoring things in any medium. > > | The proposed fix is disable all warnings, WERROR_CFLAGS= for CentOS or older > | compilers. I wonder if there is a better fix for it. > > For sure. The "implicit declaration" warning message is one that we > really need to treat as an error because it indicates a breakdown that > will cause strong type-checking to be disabled. Also, implicit > declaration of a varargs function is just wrong. > > | And also curious what > | triggered this, the commit is shuffling include files around. I could not > | figure which line is causing warning. > > It a philosophy change :-) > > When I structured Pluto, I decided that certain headers were so > pervasive that they could be #included in one central header, > reducing the clutter in each individual source file. > > This guiding idea is gone. I don't know what the replacement guiding > idea is. > > After all, "printf" should mean the same thing wherever it is used. > It is true that there are some places where it should not be used: > not every context has stdout hooked up in a meaningful way. I'm not > sure that it is meaningful in lib/libswan/addr_lookup.c. > > In any case, #include <stdio.h> should be pervasively available > (except for kernel code, I guess) so snprintf(3) is available. > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
