-
-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenBSD builds warn about string related routines and rand() determinism #861
Comments
As of late, due to recipe changes the OpenBSD (6.4 amd64 generic) worker in Buildbot farm fails to built NUT (issue #1190), all other system pass the build. Last green master-branch build still reports the sort of warnings this issue is about: http://buildbot.networkupstools.org/public/nut/builders/OpenBSD-x64/builds/1038/steps/compile/logs/warnings%20%2822%29 |
Recent builds succeed again, although still with many warnings, mostly about not using safer string length-limited operations, rand/random methods, and lately about many of the sanity-checks about data ranges that vary between platforms (to check: are those covered with macros for "tautologic" checks? does build toolkit on OpenBSD honor these, and/or does it need other warning names put into pragmas?):
as of http://buildbot.networkupstools.org/public/nut/builders/OpenBSD-x64/builds/1205/steps/compile/logs/warnings%20%28169%29 (nut-v2.7.4-4613-ge121856932.7.4.1.tar.gz => e121856 master revision) |
An OpenBSD-6.4 worker (clang-6.0.0, gcc-4.2.1) was deployed as a regular guest in the new NUT CI farm. CI recipes and The warnings/suggestions above seem to not come from compiler stack, and so do not show up in Jenkins Warnings analyzer summaries for the builds, but from the linker - it similarly notes some third-party library shared objects as using questionable methods. |
http://buildbot.networkupstools.org/public/nut/builders/OpenBSD-x64/builds/802/steps/compile/logs/warnings%20%2812%29
Note for context: seems that for some string routines, NUT might use private implementations if the target systems lacks equivalents in their standard. I am not sure if those ARE used in that build, and if the compiler warning engine knows to differentiate the same-named functions.
The text was updated successfully, but these errors were encountered: