[Swan-dev] printf called from our library [was Re: CentOS 6 "implicit declaration of function ‘printf’"]

D. Hugh Redelmeier hugh at mimosa.com
Thu Jun 20 15:11:27 UTC 2019


(I'm replying to the wrong message because I don't have the right one.)

| From: Paul Wouters <paul at nohats.ca>
| 
| On Tue, 18 Jun 2019, Andrew Cagney wrote:
| 
| > why is a library function calling printf()? (if a c file needs
| > something #include it).
| 
| Because it is used in addconn which has no logging mechanism and only
| uses stdout?

That should get fixed.

There's a general rule that I've inferred:  lib/* stuff should NOT use
printf.  There's no reason to believe that stdout and stding go
anwhere at all.

Saying that it should be fixed is easier than fixing it.

In some parts of the library, error reports are returned to the
caller, making the caller resposible for appropriate disposition of
the report.  That's the easiest solution but not always optimal.

If a library routine needs to do more intricate logging, lswlog.h
stuff should be used.  And things that call the library should make
sure that lswlog.h functions will work.

| There are also many calls to fprintf() within the test compile
| sections
| when some files are compiled with "main()" enabled. Since I dont think
| we ever used this in libreswan for any testing, I'd prefer to remove
| all of those.

Henry carefully built unit tests.  Unit tests are a Good Thing.  We
should have and use more unit tests rather than fewer.

I'm regret not writing unit tests for Pluto.  We don't even have a
framework in which to do it.  It's always to late too add this.

Wholesale deleting of unit tests seems like a barbaric act.

It may be the case that if we started running these unit tests again,
they would fail.  That just means we have to fix the functions or fix
the tests.  Do not delete a test unlesss we delete the function being
tested.

If we have to fix the tests, we should check whether we have to fix
the corresponding man pages.  They too may have suffered bit-rot.


More information about the Swan-dev mailing list