-
Notifications
You must be signed in to change notification settings - Fork 166
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
Fix yaml parser error when meets .nan #741
Conversation
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
c65d7e1
to
d12c0f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides the inline comment, can you also please add a test for this case? Thanks.
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
d5a457f
to
d326731
Compare
|
Close this by accident... never mind. |
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for iterating on this! This is exactly what I was looking for.
I have a few more minor comments inline, and this also needs to be rebased. Once that happens, I'll run CI on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with @clalancette 's comments.
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
I think this is ready to be merged, please has a re-review. Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, Windows is failing because it doesn't like |
what about using |
It sounds like this PR can be merged as soon as it passes CI. #754 is not blocking anything at the moment, so I'm happy to rebase it on top of this PR. |
@clalancette @fujitatomoya
|
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
#ifdef _WIN32 | ||
#define strcasecmp stricmp | ||
#endif | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that there is no standard case insensitive string compare in C. but I am negative on this, this will cause complication and dependency especially for maintenance. (at least i believe that this is not the right place.) Instead of this, we would create rcutils_strcasecmp
based on strcasecmp
and stricmp
? Any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I have to agree that it would be nicer to have a rcutils_strcasecmp
, rather than putting the compatibility code in here. So I'll suggest a new PR to rcutils to do that (sorry that this is going to drag out a bit longer).
For what it is worth, there are 2 different ways we could go about this. One is that we could define rcutils_strcasecmp
based on either strcasecmp
or stricmp
, as you mention above. The other way to do it is to just implement it ourselves, since it is a pretty easy function:
int rcutils_strcasecmp(const char *s1, const char *s2)
{
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
int result;
if (p1 == p2) {
return 0;
}
while ((result = tolower(*p1) - tolower(*p2++)) == 0) {
if (*p1++ == '\0') {
break;
}
}
return result;
}
(that code comes from glibc with some minor edits by me). I'm fine with either option, just thought I'd point out that both were available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's open new PR as discussed here and then get back on this!
One is that we could define rcutils_strcasecmp based on either strcasecmp or stricmp
I am good to with either way, but I personally would prefer this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just created ros2/rcutils#279 and ros2/rcutils#280.
ASSERT_EQ(9U, param_value->double_array_value->size); | ||
EXPECT_TRUE(std::isnan(param_value->double_array_value->values[2])); | ||
EXPECT_TRUE(std::isnan(param_value->double_array_value->values[3])); | ||
EXPECT_TRUE(std::isinf(param_value->double_array_value->values[4])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About inf, there are positive infinity and negative infinity.
isinf(x) returns 1 if x is positive infinity, and -1 if x is negative infinity.
Maybe it should be
EXPECT_TRUE(std::isinf(param_value->double_array_value->values[4]) == 1);
EXPECT_TRUE(std::isinf(param_value->double_array_value->values[5]) == -1);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that make sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The type of return value in c++ is bool
, so the current test is sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, It's my bad (not to check the c++ version).
I will use c version isinf
to check the result accurately, anyway, it's up to you.
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
@fujitatomoya @clalancette friendly ping |
Signed-off-by: Ada-King <Bingtao.Du@sony.com>
if ((0 == strcmp(value, ".nan")) || | ||
(0 == strcmp(value, ".NaN")) || | ||
(0 == strcmp(value, ".NAN")) || | ||
(0 == strcmp(value, ".inf")) || | ||
(0 == strcmp(value, ".Inf")) || | ||
(0 == strcmp(value, ".INF")) || | ||
(0 == strcmp(value, "+.inf")) || | ||
(0 == strcmp(value, "+.Inf")) || | ||
(0 == strcmp(value, "+.INF")) || | ||
(0 == strcmp(value, "-.inf")) || | ||
(0 == strcmp(value, "-.Inf")) || | ||
(0 == strcmp(value, "-.INF"))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we get ros2/rcutils#280 in, we can change this code to use rcutils_strcasecmp
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we get ros2/rcutils#280 in, we can change this code to use
rcutils_strcasecmp
.
@clalancette
FYI (#741 (comment))
The yaml spec only allows specific formats.
Besides, the existed build error doesn't seem to be caused by this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ros-pull-request-builder retest this please |
The refactoring PR #754 was merged in order to make progress on adding in coverage unit tests. Rebasing this PR on master should be fairly straightforward. The modified logic in PR with squashed commits rebased onto master |
I'm going to close this one out in favor of #781; we can continue the discussion over there. |
Related issue 555
The problem has examined on my host machine.
Signed-off-by: Ada-King Bingtao.Du@sony.com