same code, same library version, same compiler, different output
up vote
4
down vote
favorite
File h.cpp
#include "yaml-cpp/yaml.h"
#include <iostream>
int main() {
YAML::Node node = YAML::Load("[1, 2, 3]");
std::cout << node << "n";
std::cout << node.Type() << "n";
std::cout << node.IsSequence() << "n";
}
compiled and executed with
g++ -lyaml-cpp h.cpp && ./a.out
yields
[1, 2, 3]
3
1
on my desktop, but
[1, 2, 3]
1
0
on my laptop. The last line of laptop output is wrong: For sure, the given YAML string is a sequence.
Same results when g++ is replaced by clang++. Both machines run the same Debian 4.18.10-2, both are x86_64, both run Linux 4.18.0-2-amd64, both have same versions of g++ and clang++. Both have the same yaml-cpp library versions, freshly reinstalled:
$ locate libyaml-cpp.
/usr/lib/x86_64-linux-gnu/libyaml-cpp.a
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
libyaml-cpp-dev: /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
libyaml-cpp0.5v5:amd64: /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ apt-cache show libyaml-cpp-dev
Package: libyaml-cpp-dev
Source: yaml-cpp
Version: 0.5.2-4
$ apt-cache show libyaml-cpp0.5v5
Package: libyaml-cpp0.5v5
Source: yaml-cpp
Version: 0.5.2-4
Output from ldd is identical except for the hex addresses in parentheses:
$ ldd a.out
linux-vdso.so.1 (0x00007ffd0d5f0000)
libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007f1e9fcd8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1e9fb55000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e9f9c1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1e9f9a7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e9f7ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e9ff79000)
What possible explanations remain in such a situation?
c++ yaml-cpp
asked Nov 9 at 22:41
Joachim W
2,39831329
|
show 2 more comments
up vote
4
down vote
favorite
File h.cpp
#include "yaml-cpp/yaml.h"
#include <iostream>
int main() {
YAML::Node node = YAML::Load("[1, 2, 3]");
std::cout << node << "n";
std::cout << node.Type() << "n";
std::cout << node.IsSequence() << "n";
}
compiled and executed with
g++ -lyaml-cpp h.cpp && ./a.out
yields
[1, 2, 3]
3
1
on my desktop, but
[1, 2, 3]
1
0
on my laptop. The last line of laptop output is wrong: For sure, the given YAML string is a sequence.
Same results when g++ is replaced by clang++. Both machines run the same Debian 4.18.10-2, both are x86_64, both run Linux 4.18.0-2-amd64, both have same versions of g++ and clang++. Both have the same yaml-cpp library versions, freshly reinstalled:
$ locate libyaml-cpp.
/usr/lib/x86_64-linux-gnu/libyaml-cpp.a
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
libyaml-cpp-dev: /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
libyaml-cpp0.5v5:amd64: /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ apt-cache show libyaml-cpp-dev
Package: libyaml-cpp-dev
Source: yaml-cpp
Version: 0.5.2-4
$ apt-cache show libyaml-cpp0.5v5
Package: libyaml-cpp0.5v5
Source: yaml-cpp
Version: 0.5.2-4
Output from ldd is identical except for the hex addresses in parentheses:
$ ldd a.out
linux-vdso.so.1 (0x00007ffd0d5f0000)
libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007f1e9fcd8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1e9fb55000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e9f9c1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1e9f9a7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e9f7ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e9ff79000)
What possible explanations remain in such a situation?
c++ yaml-cpp
asked Nov 9 at 22:41
Joachim W
2,39831329
2
You may not be running thea.outyou think you are running in one or both environments, especially if thePATHdiffers between the two. Avoid this risk by specifically executing./a.outinstead of relying on a path lookup to find the executable.
– John Bollinger
Nov 9 at 22:46
Valid point, but not the explanation here. I'll edit the question to rule out this possibility.
– Joachim W
Nov 9 at 23:05
2
The most reasonable explanation is the YAML library is having undefined behavior. You can try running it under sanitizers or manually check the code.
– Dani
Nov 9 at 23:09
It might be helpful to see what this outputs:std::cout << node.Type() << " : " << YAML::NodeType::Sequence << "n";
– David Schwartz
Nov 10 at 0:04
node.Type()output also differs,3vs1
– Joachim W
Nov 10 at 6:16
|
show 2 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
File h.cpp
#include "yaml-cpp/yaml.h"
#include <iostream>
int main() {
YAML::Node node = YAML::Load("[1, 2, 3]");
std::cout << node << "n";
std::cout << node.Type() << "n";
std::cout << node.IsSequence() << "n";
}
compiled and executed with
g++ -lyaml-cpp h.cpp && ./a.out
yields
[1, 2, 3]
3
1
on my desktop, but
[1, 2, 3]
1
0
on my laptop. The last line of laptop output is wrong: For sure, the given YAML string is a sequence.
Same results when g++ is replaced by clang++. Both machines run the same Debian 4.18.10-2, both are x86_64, both run Linux 4.18.0-2-amd64, both have same versions of g++ and clang++. Both have the same yaml-cpp library versions, freshly reinstalled:
$ locate libyaml-cpp.
/usr/lib/x86_64-linux-gnu/libyaml-cpp.a
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
libyaml-cpp-dev: /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
libyaml-cpp0.5v5:amd64: /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ apt-cache show libyaml-cpp-dev
Package: libyaml-cpp-dev
Source: yaml-cpp
Version: 0.5.2-4
$ apt-cache show libyaml-cpp0.5v5
Package: libyaml-cpp0.5v5
Source: yaml-cpp
Version: 0.5.2-4
Output from ldd is identical except for the hex addresses in parentheses:
$ ldd a.out
linux-vdso.so.1 (0x00007ffd0d5f0000)
libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007f1e9fcd8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1e9fb55000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e9f9c1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1e9f9a7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e9f7ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e9ff79000)
What possible explanations remain in such a situation?
c++ yaml-cpp
asked Nov 9 at 22:41
Joachim W
2,39831329
File h.cpp
#include "yaml-cpp/yaml.h"
#include <iostream>
int main() {
YAML::Node node = YAML::Load("[1, 2, 3]");
std::cout << node << "n";
std::cout << node.Type() << "n";
std::cout << node.IsSequence() << "n";
}
compiled and executed with
g++ -lyaml-cpp h.cpp && ./a.out
yields
[1, 2, 3]
3
1
on my desktop, but
[1, 2, 3]
1
0
on my laptop. The last line of laptop output is wrong: For sure, the given YAML string is a sequence.
Same results when g++ is replaced by clang++. Both machines run the same Debian 4.18.10-2, both are x86_64, both run Linux 4.18.0-2-amd64, both have same versions of g++ and clang++. Both have the same yaml-cpp library versions, freshly reinstalled:
$ locate libyaml-cpp.
/usr/lib/x86_64-linux-gnu/libyaml-cpp.a
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5
/usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
libyaml-cpp-dev: /usr/lib/x86_64-linux-gnu/libyaml-cpp.a
$ dpkg -S /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
libyaml-cpp0.5v5:amd64: /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5.2
$ apt-cache show libyaml-cpp-dev
Package: libyaml-cpp-dev
Source: yaml-cpp
Version: 0.5.2-4
$ apt-cache show libyaml-cpp0.5v5
Package: libyaml-cpp0.5v5
Source: yaml-cpp
Version: 0.5.2-4
Output from ldd is identical except for the hex addresses in parentheses:
$ ldd a.out
linux-vdso.so.1 (0x00007ffd0d5f0000)
libyaml-cpp.so.0.5 => /usr/lib/x86_64-linux-gnu/libyaml-cpp.so.0.5 (0x00007f1e9fcd8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1e9fb55000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e9f9c1000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1e9f9a7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e9f7ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e9ff79000)
What possible explanations remain in such a situation?
c++ yaml-cpp
c++ yaml-cpp
asked Nov 9 at 22:41
Joachim W
2,39831329
asked Nov 9 at 22:41
Joachim W
2,39831329
edited Nov 10 at 21:28
asked Nov 9 at 22:41
Joachim W
2,39831329
asked Nov 9 at 22:41
Joachim W
2,39831329
asked Nov 9 at 22:41
Joachim W
2,39831329
2,39831329
2
You may not be running thea.outyou think you are running in one or both environments, especially if thePATHdiffers between the two. Avoid this risk by specifically executing./a.outinstead of relying on a path lookup to find the executable.
– John Bollinger
Nov 9 at 22:46
Valid point, but not the explanation here. I'll edit the question to rule out this possibility.
– Joachim W
Nov 9 at 23:05
2
The most reasonable explanation is the YAML library is having undefined behavior. You can try running it under sanitizers or manually check the code.
– Dani
Nov 9 at 23:09
It might be helpful to see what this outputs:std::cout << node.Type() << " : " << YAML::NodeType::Sequence << "n";
– David Schwartz
Nov 10 at 0:04
node.Type()output also differs,3vs1
– Joachim W
Nov 10 at 6:16
|
show 2 more comments
2
You may not be running thea.outyou think you are running in one or both environments, especially if thePATHdiffers between the two. Avoid this risk by specifically executing./a.outinstead of relying on a path lookup to find the executable.
– John Bollinger
Nov 9 at 22:46
Valid point, but not the explanation here. I'll edit the question to rule out this possibility.
– Joachim W
Nov 9 at 23:05
2
The most reasonable explanation is the YAML library is having undefined behavior. You can try running it under sanitizers or manually check the code.
– Dani
Nov 9 at 23:09
It might be helpful to see what this outputs:std::cout << node.Type() << " : " << YAML::NodeType::Sequence << "n";
– David Schwartz
Nov 10 at 0:04
node.Type()output also differs,3vs1
– Joachim W
Nov 10 at 6:16
2
2
You may not be running the
a.out you think you are running in one or both environments, especially if the PATH differs between the two. Avoid this risk by specifically executing ./a.out instead of relying on a path lookup to find the executable.– John Bollinger
Nov 9 at 22:46
You may not be running the
a.out you think you are running in one or both environments, especially if the PATH differs between the two. Avoid this risk by specifically executing ./a.out instead of relying on a path lookup to find the executable.– John Bollinger
Nov 9 at 22:46
Valid point, but not the explanation here. I'll edit the question to rule out this possibility.
– Joachim W
Nov 9 at 23:05
Valid point, but not the explanation here. I'll edit the question to rule out this possibility.
– Joachim W
Nov 9 at 23:05
2
2
The most reasonable explanation is the YAML library is having undefined behavior. You can try running it under sanitizers or manually check the code.
– Dani
Nov 9 at 23:09
The most reasonable explanation is the YAML library is having undefined behavior. You can try running it under sanitizers or manually check the code.
– Dani
Nov 9 at 23:09
It might be helpful to see what this outputs:
std::cout << node.Type() << " : " << YAML::NodeType::Sequence << "n";– David Schwartz
Nov 10 at 0:04
It might be helpful to see what this outputs:
std::cout << node.Type() << " : " << YAML::NodeType::Sequence << "n";– David Schwartz
Nov 10 at 0:04
node.Type() output also differs, 3 vs 1– Joachim W
Nov 10 at 6:16
node.Type() output also differs, 3 vs 1– Joachim W
Nov 10 at 6:16
|
show 2 more comments
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
The bug disappears if I replace libyaml-cpp-0.5 from Debian by the current master branch (post 0.6.2) from the libyaml-cpp git repository. This strongly supports the hypothesis that the cause of the bug is undefined behavior in libyaml-cpp.
I won't investigate further. For the time being, I'll use version 0.6. In the long run, I will migrate to the C library libyaml, which is much more stable than libyaml-cpp.
answered Dec 1 at 21:31
Joachim W
2,39831329
Unless the bug has been specifically identified the idea of "no need to investigate further" seems quite questionable. When are you going to investigate? after the airplane exploded? If it was for example a consequence of uninitialized variable or undefined behavior in the code may be that now the code "works" by accidente, ready to bite harder later.
– 6502
Dec 1 at 21:36
@6502. Valid points. I edited my answer in response.
– Joachim W
Dec 1 at 21:43
Interesting question though: how probable is it that an unmature library like libyaml-cpp makes it into airplane software?
– Joachim W
Dec 1 at 21:46
1
Zero, I hope, but that's not my decision. I didn't know the library but after taking a look at a just one file (binary.cpp, the first in alphabetical order, handling base64) I can already see a couple of problems (it usesstd::isspace(input[i])forgetting the mandatory cast to(unsigned char)and also whitespace is skipped over, but this is not considered when checking if the "previous" char atinput[i-1]is an equal sign or not... what if the previous char was skipped over?).
– 6502
Dec 1 at 22:55
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53234192%2fsame-code-same-library-version-same-compiler-different-output%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
The bug disappears if I replace libyaml-cpp-0.5 from Debian by the current master branch (post 0.6.2) from the libyaml-cpp git repository. This strongly supports the hypothesis that the cause of the bug is undefined behavior in libyaml-cpp.
I won't investigate further. For the time being, I'll use version 0.6. In the long run, I will migrate to the C library libyaml, which is much more stable than libyaml-cpp.
answered Dec 1 at 21:31
Joachim W
2,39831329
Unless the bug has been specifically identified the idea of "no need to investigate further" seems quite questionable. When are you going to investigate? after the airplane exploded? If it was for example a consequence of uninitialized variable or undefined behavior in the code may be that now the code "works" by accidente, ready to bite harder later.
– 6502
Dec 1 at 21:36
@6502. Valid points. I edited my answer in response.
– Joachim W
Dec 1 at 21:43
Interesting question though: how probable is it that an unmature library like libyaml-cpp makes it into airplane software?
– Joachim W
Dec 1 at 21:46
1
Zero, I hope, but that's not my decision. I didn't know the library but after taking a look at a just one file (binary.cpp, the first in alphabetical order, handling base64) I can already see a couple of problems (it usesstd::isspace(input[i])forgetting the mandatory cast to(unsigned char)and also whitespace is skipped over, but this is not considered when checking if the "previous" char atinput[i-1]is an equal sign or not... what if the previous char was skipped over?).
– 6502
Dec 1 at 22:55
add a comment |
up vote
1
down vote
accepted
The bug disappears if I replace libyaml-cpp-0.5 from Debian by the current master branch (post 0.6.2) from the libyaml-cpp git repository. This strongly supports the hypothesis that the cause of the bug is undefined behavior in libyaml-cpp.
I won't investigate further. For the time being, I'll use version 0.6. In the long run, I will migrate to the C library libyaml, which is much more stable than libyaml-cpp.
answered Dec 1 at 21:31
Joachim W
2,39831329
Unless the bug has been specifically identified the idea of "no need to investigate further" seems quite questionable. When are you going to investigate? after the airplane exploded? If it was for example a consequence of uninitialized variable or undefined behavior in the code may be that now the code "works" by accidente, ready to bite harder later.
– 6502
Dec 1 at 21:36
@6502. Valid points. I edited my answer in response.
– Joachim W
Dec 1 at 21:43
Interesting question though: how probable is it that an unmature library like libyaml-cpp makes it into airplane software?
– Joachim W
Dec 1 at 21:46
1
Zero, I hope, but that's not my decision. I didn't know the library but after taking a look at a just one file (binary.cpp, the first in alphabetical order, handling base64) I can already see a couple of problems (it usesstd::isspace(input[i])forgetting the mandatory cast to(unsigned char)and also whitespace is skipped over, but this is not considered when checking if the "previous" char atinput[i-1]is an equal sign or not... what if the previous char was skipped over?).
– 6502
Dec 1 at 22:55
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
The bug disappears if I replace libyaml-cpp-0.5 from Debian by the current master branch (post 0.6.2) from the libyaml-cpp git repository. This strongly supports the hypothesis that the cause of the bug is undefined behavior in libyaml-cpp.
I won't investigate further. For the time being, I'll use version 0.6. In the long run, I will migrate to the C library libyaml, which is much more stable than libyaml-cpp.
answered Dec 1 at 21:31
Joachim W
2,39831329
The bug disappears if I replace libyaml-cpp-0.5 from Debian by the current master branch (post 0.6.2) from the libyaml-cpp git repository. This strongly supports the hypothesis that the cause of the bug is undefined behavior in libyaml-cpp.
I won't investigate further. For the time being, I'll use version 0.6. In the long run, I will migrate to the C library libyaml, which is much more stable than libyaml-cpp.
answered Dec 1 at 21:31
Joachim W
2,39831329
edited Dec 1 at 21:54
answered Dec 1 at 21:31
Joachim W
2,39831329
answered Dec 1 at 21:31
Joachim W
2,39831329
answered Dec 1 at 21:31
Joachim W
2,39831329
2,39831329
Unless the bug has been specifically identified the idea of "no need to investigate further" seems quite questionable. When are you going to investigate? after the airplane exploded? If it was for example a consequence of uninitialized variable or undefined behavior in the code may be that now the code "works" by accidente, ready to bite harder later.
– 6502
Dec 1 at 21:36
@6502. Valid points. I edited my answer in response.
– Joachim W
Dec 1 at 21:43
Interesting question though: how probable is it that an unmature library like libyaml-cpp makes it into airplane software?
– Joachim W
Dec 1 at 21:46
1
Zero, I hope, but that's not my decision. I didn't know the library but after taking a look at a just one file (binary.cpp, the first in alphabetical order, handling base64) I can already see a couple of problems (it usesstd::isspace(input[i])forgetting the mandatory cast to(unsigned char)and also whitespace is skipped over, but this is not considered when checking if the "previous" char atinput[i-1]is an equal sign or not... what if the previous char was skipped over?).
– 6502
Dec 1 at 22:55
add a comment |
Unless the bug has been specifically identified the idea of "no need to investigate further" seems quite questionable. When are you going to investigate? after the airplane exploded? If it was for example a consequence of uninitialized variable or undefined behavior in the code may be that now the code "works" by accidente, ready to bite harder later.
– 6502
Dec 1 at 21:36
@6502. Valid points. I edited my answer in response.
– Joachim W
Dec 1 at 21:43
Interesting question though: how probable is it that an unmature library like libyaml-cpp makes it into airplane software?
– Joachim W
Dec 1 at 21:46
1
Zero, I hope, but that's not my decision. I didn't know the library but after taking a look at a just one file (binary.cpp, the first in alphabetical order, handling base64) I can already see a couple of problems (it usesstd::isspace(input[i])forgetting the mandatory cast to(unsigned char)and also whitespace is skipped over, but this is not considered when checking if the "previous" char atinput[i-1]is an equal sign or not... what if the previous char was skipped over?).
– 6502
Dec 1 at 22:55
Unless the bug has been specifically identified the idea of "no need to investigate further" seems quite questionable. When are you going to investigate? after the airplane exploded? If it was for example a consequence of uninitialized variable or undefined behavior in the code may be that now the code "works" by accidente, ready to bite harder later.
– 6502
Dec 1 at 21:36
Unless the bug has been specifically identified the idea of "no need to investigate further" seems quite questionable. When are you going to investigate? after the airplane exploded? If it was for example a consequence of uninitialized variable or undefined behavior in the code may be that now the code "works" by accidente, ready to bite harder later.
– 6502
Dec 1 at 21:36
@6502. Valid points. I edited my answer in response.
– Joachim W
Dec 1 at 21:43
@6502. Valid points. I edited my answer in response.
– Joachim W
Dec 1 at 21:43
Interesting question though: how probable is it that an unmature library like libyaml-cpp makes it into airplane software?
– Joachim W
Dec 1 at 21:46
Interesting question though: how probable is it that an unmature library like libyaml-cpp makes it into airplane software?
– Joachim W
Dec 1 at 21:46
1
1
Zero, I hope, but that's not my decision. I didn't know the library but after taking a look at a just one file (binary.cpp, the first in alphabetical order, handling base64) I can already see a couple of problems (it uses
std::isspace(input[i]) forgetting the mandatory cast to (unsigned char) and also whitespace is skipped over, but this is not considered when checking if the "previous" char at input[i-1] is an equal sign or not... what if the previous char was skipped over?).– 6502
Dec 1 at 22:55
Zero, I hope, but that's not my decision. I didn't know the library but after taking a look at a just one file (binary.cpp, the first in alphabetical order, handling base64) I can already see a couple of problems (it uses
std::isspace(input[i]) forgetting the mandatory cast to (unsigned char) and also whitespace is skipped over, but this is not considered when checking if the "previous" char at input[i-1] is an equal sign or not... what if the previous char was skipped over?).– 6502
Dec 1 at 22:55
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53234192%2fsame-code-same-library-version-same-compiler-different-output%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
You may not be running the
a.outyou think you are running in one or both environments, especially if thePATHdiffers between the two. Avoid this risk by specifically executing./a.outinstead of relying on a path lookup to find the executable.– John Bollinger
Nov 9 at 22:46
Valid point, but not the explanation here. I'll edit the question to rule out this possibility.
– Joachim W
Nov 9 at 23:05
2
The most reasonable explanation is the YAML library is having undefined behavior. You can try running it under sanitizers or manually check the code.
– Dani
Nov 9 at 23:09
It might be helpful to see what this outputs:
std::cout << node.Type() << " : " << YAML::NodeType::Sequence << "n";– David Schwartz
Nov 10 at 0:04
node.Type()output also differs,3vs1– Joachim W
Nov 10 at 6:16