https://bugzilla.redhat.com/show_bug.cgi?id=1987298
Ben Beasley <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(code@musicinmybra | |in.net) | --- Comment #6 from Ben Beasley <[email protected]> --- I have added a build conditional to cease packaging the stb_include library: > # We choose not to package the “stb_include” library (stb_include.h) because > it > # is so rife with old-school blithe C behavior—wanton use of strcat/strcpy > into > # a fixed-length buffer that is assumed (but not proven) to be large enough > for > # all possible uses, ignoring possible I/O errors (possibly leading to > # undefined behavior from reading uninitialized memory), and so on. Making it > # safe to use would mean a substantial rewrite. > # > # If a request for this library arises, this decision may be revisited, or the > # necessary rewrite may be done and offered upstream. For now, we omit the > # library and expect it will not be missed. > %bcond_with stb_include I also filed https://github.com/nothings/stb/issues/1193. I have patched some of the most serious and/or most easily fixed issues highlighted by the compiler warnings: https://github.com/nothings/stb/pull/1194 https://github.com/nothings/stb/pull/1195 https://github.com/nothings/stb/pull/1196 There are still some compiler warnings. Most are unused functions or variables—most of those related to preprocessor conditionals. Those warnings that still hint at real issues are difficult to evaluate. I filed one additional issue, https://github.com/nothings/stb/issues/1197. I am leaving this alone: > In file included from /usr/include/string.h:519, > from ../stb_ds.h:395, > from test_cpp_compilation.cpp:13: > In function 'memcpy', > inlined from 'stbi__getn(stbi__context*, unsigned char*, int)' at > ../stb_image.h:1653:16, > inlined from 'stbi__parse_png_file(stbi__png*, int, int) [clone > .constprop.0]' at ../stb_image.h:5123:28: > /usr/include/bits/string_fortified.h:29:33: warning: 'memcpy' specified bound > between 18446744071562067968 and 18446744073709551615 exceeds maximum object > size 9223372036854775807 [-Wstringop-overflow=] > 29 | return __builtin___memcpy_chk (__dest, __src, __len, > | ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~ > 30 | __glibc_objsize0 (__dest)); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~ which I *think* is pointing out that a sufficiently large 32-bit unsigned chunk length may be cast to a negative int, which is then interpreted as a huge positive number of bytes to memcpy; but whether this can actually happen in practice is much harder to tell. (I ignore here the possibility that int could be shorter than 32 bits on some platform…) In any case, I’m sure that looking closely and turning over a few rocks (i.e., compiling with clang-analyzer/scan-build, or trying to fuzz some of the libraries) could reveal dozens of similar issues in short order. Still, let me know if you think there’s anything else I should deal with before proceeding with the package. Updated spec URL: https://music.fedorapeople.org/20210819/stb.spec Updated SRPM URL: https://music.fedorapeople.org/20210819/stb-0-0.1.20210728git3a11740.fc34.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
