On Freitag, 19. Januar 2018 20:08:10 CET Christian wrote:

hi,

when building I get: [ 1703s] ... running 01-check-debuginfo [ 1703s] ... testing for empty debuginfo packages [ 1703s] ... running 02-check-gcc-output [ 1703s] ... testing for serious compiler warnings [ 1703s] (using /usr/lib/build/checks-data/check_gcc_output) [ 1703s] (using /srv/oscbuild/openSUSE_42.3-x86_64/.build.log) [ 1703s] [ 1703s] I: Expression compares a char* pointer with a string literal. [ 1703s] Usually a strcmp() was intended by the programmer [ 1703s] E: palemoon stringcompare /home/abuild/rpmbuild/BUILD/Pale-Moon-27.7.1_Release/toolkit/xre/nsAppRunner .cpp:3597

I did report it upstream and got this: https://github.com/MoonchildProductions/Pale-Moon/issues/1581

AFAIK I am not a developer. So who is right ? wolfbeast or /usr/lib/build/checks-data/check_gcc_output

The author apparently lacks any C/C++ knowledge ... http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf 5.13.5 String literals, paragraph 16 Evaluating a string-literal results in a string literal object with static storage duration, initialized from the given characters as specified above. Whether all string literals are distinct (that is, are stored in nonoverlapping objects) and whether successive evaluations of a string-literal yield the same or a different object is unspecified. [ Note: The effect of attempting to modify a string literal is undefined. — end note ] Note the "unspecified" in the paragraph above. Kind regards, Stefan N�����r��y隊Z)z{.���Wlz��qﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǜ�)]���Ǿ� ޮ�^�ˬz��

On Sat, Jan 20, 2018 at 12:21 PM, Christian wrote:

Am 19.01.2018 um 22:56 schrieb Brüns, Stefan:

...

The author apparently lacks any C/C++ knowledge ... Looks like wolfbeast is not right. But he is behaving as if he 'wrote' C/C++ himself ...

...

Note the "unspecified" in the paragraph above.

Thanks for the doc snippet, but as a non-developer I don't understand it.

"unspecified" and "undefined" basically mean that the behavior is not set on how to handle such a case. That means that it's more or less up to the compiler. And while the compiler will attempt to resolve the issue, the way it does is not guaranteed to be consistent, reproducible, or even sane. Markus Straver (the author of Pale Moon) develops primarily on Windows with the lazy MSVC compiler (MSVC 2012[1]), so he won't notice much from stricter compilers. In fact, last I checked, the project actively advises against building Pale Moon with anything newer than GCC 4.9 anyway[2]. They don't have CI or bother to try to make modern compilers like GCC or Clang part of their testing, and do not actively try to resolve issues detected by the compiler. I'm honestly surprised Pale Moon is available somewhere for openSUSE, given how much they go out of their way to make things better on Linux. [1]: https://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/... [2]: https://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org