>On Sun, Jan 4, 2015, at 01:09 AM, Stuart Henderson wrote: >> On 2014/12/25 21:28, Adam Wolk wrote: >> > 2. gcc warnings after compilation >> > Linking CXX executable otter-browser >> > /usr/local/lib/qt5/libQt5Script.so.0.0: warning: random() may return >> > deterministic values, is that what you want? >> > /usr/local/lib/qt5/libQt5WebKit.so.0.0: warning: strcpy() is almost >> > always misused, please use strlcpy() >> > /usr/local/lib/qt5/libQt5Core.so.0.0: warning: rand() may return >> > deterministic values, is that what you want? >> > /usr/local/lib/qt5/libQt5Script.so.0.0: warning: sprintf() is often >> > misused, please use snprintf() >> > /usr/X11R6/lib/libX11.so.16.0: warning: strcat() is almost always >> > misused, please use strlcat() >> > /usr/local/lib/libglib-2.0.so.4200.0: warning: stpcpy() is dangerous; do >> > not use it >> > /usr/local/lib/libglib-2.0.so.4200.0: warning: vsprintf() is often >> > misused, please use vsnprintf() >> >> These are api warnings from the linker, unfortunately fairly common to >> trigger them when porting software, they're mostly helpful for people >> using OpenBSD as a dev platform (and as a bit of a warning to porters >> that >> some things might be worse than usual ;) >> >Just reporting what I see. Worse then usual? I prefer to know that >something potentially isn't >working as expected so happy to be notified by OpenBSD about it :)
Many software projects are still slowly fixing these problems. The most important issues are likely solved, but OpenBSD's linker warns about them all in any case because it does not have any information to indicate they are safe. Often times the codebases are not improving specifically because of OpenBSD's warnings, but mostly because programmer standards have improved. These are the last few they haven't cleaned. Few years ago this was probably pages of output. In any case, these messages nag at projects to fix the stragglers, just in case. They know those strcpy and sprintf and strcpy calls just might be called without the right bounded checks, and they need to keep re-verifying the code by eye. This would not be needed if the right calls were used. As well, it is completely obvious that the random generators in here are supposed to be deterministic and non-random, not much better than seed++, certainly nothing cryptographic or is happening here, and certainly this library is not linked against any application which will require rand() or random() to behave independently deterministic, either, because mixing this in a library and a program breaks that assumption. So bit by bit this gets better.
