Skip to content
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

Clarify that a test failed #3423

Closed
wants to merge 2 commits into from

Conversation

levitte
Copy link
Member

@levitte levitte commented May 10, 2017

Checklist
  • tests are added or updated

@levitte levitte added the branch: master Merge to master branch label May 10, 2017
@levitte levitte requested a review from dot-asm May 10, 2017 08:02
@dot-asm
Copy link
Contributor

dot-asm commented May 10, 2017

Suggestion was rather ERROR: (type) 'expression' failed, i.e. more human-friendly. To me ERROR: (type) failed: expression is as human-unfriendly as original, just mechanic collection of words. It would have been a little bit better if not for (type) prior failed:.

@levitte
Copy link
Member Author

levitte commented May 10, 2017

The reason for failed: placed like that is to prevent the readability problem of quotes in quotes. Examples:

TEST_char_eq(c, 'v') 
TEST_str_eq(s, "foo") 

@dot-asm
Copy link
Contributor

dot-asm commented May 10, 2017

readability problem of quotes in quotes

But does it justify ERROR: (char) failed: c == 'v'. Is (char) failed: readable?

@levitte
Copy link
Member Author

levitte commented May 10, 2017

I'm biased, so I'll let someone else answer your question

@richsalz
Copy link
Contributor

The only output that's generated is failure messages. I think the trade-offs of common infrastructure, many more things being checked (e.g., malloc failures), and making things easier for the future are strong arguments in favor of this. (And also for #3324). But I recognize that Andy does more work in assembler and porting to strange platforms then the rest of the time. But but, I wonder if he'll really have a problem understanding the test failure messages now.

So overall, I'm in favor. I hope andy will come around, but unless he explicitly minus-one's this, I approve.

@dot-asm
Copy link
Contributor

dot-asm commented May 10, 2017

My point is that errors are [supposed to be] rare, i.e. you have to imagine how would it appear to you say 1/2 year later when you've forgotten all about this PR. Would you appreciate if you have to struggle remembering what does given combination of words mean? Once again, are computers for people or vice versa? This has nothing to do with what I do. ERROR: (type) failed: ... is not any better than ERROR: (type) ..., so as far as I'm concerned it can as well be omitted...

@levitte
Copy link
Member Author

levitte commented May 10, 2017

ERROR: (type) failed: ... is not any better than ERROR: (type) ..., so as far as I'm concerned it can as well be omitted...

I disagree. However, I just pushed another commit that outputs things like you suggested. It means that we get output like this for some of the character tests:

    # ERROR: (char) ''x' < 'i'' failed @ ../master/test/test_test.c:89
    # [x] compared to [i]

@dot-asm
Copy link
Contributor

dot-asm commented May 10, 2017

You put me into impossible position. You disagree and have Rich on your side, then why change? I naturally in favour, but now it's up to Rich to decide...

[Signing off for today, sorry.]

@levitte
Copy link
Member Author

levitte commented May 10, 2017

I specifically disagree that the added failed: makes no difference. I remade the output because I don't necessarely disagree with your point about the look of the output, I just saw a quote problem. Two different points.

If anyone else is fine with the quoted output, I'm fine with this look.

@richsalz
Copy link
Contributor

+1
Andy, we try to make sure everyone on the team is in agreement, even though the rules only require one or two approvals :)

@paulidale
Copy link
Contributor

Losing the (type) or putting it at the end of the line not the start would also be an option.

@dot-asm dot-asm added the approval: done This pull request has the required number of approvals label May 11, 2017
levitte added a commit that referenced this pull request May 11, 2017
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from #3423)
@levitte
Copy link
Member Author

levitte commented May 11, 2017

Merged. 4f2a569

(darn, momentary lapse, I didn't add @richsalz as reviewer... unfortunately, since we don't allow fastforwarding in our repo, this can't be undone)

@richsalz
Copy link
Contributor

I can live with the anonymity :)

@levitte
Copy link
Member Author

levitte commented May 11, 2017

Okie

@levitte levitte closed this May 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approval: done This pull request has the required number of approvals branch: master Merge to master branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants