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

max is divided by 2 #70

Open
tcharding opened this issue Feb 13, 2024 · 2 comments
Open

max is divided by 2 #70

tcharding opened this issue Feb 13, 2024 · 2 comments
Labels
1.0 Issues and PRs required or helping to stabilize the API

Comments

@tcharding
Copy link
Member

tcharding commented Feb 13, 2024

EDIT: Probably not worth reading this issue, just see #71

I'm pretty sure this line of code is wrong but I can't come up with a unit test to prove it. Patching it to what I think it should be does not break any unit tests.

Some(max) if self.bytes.len() * 2 > (max + 1) / 2 => max,

We are dividing the max string length by 2 as well as multiplying the number of bytes by 2 - we should just do one (I believe).

            let string_len = match f.precision() {
                Some(max) if self.bytes.len() * 2 > (max + 1) / 2 => max,
                Some(_) | None => self.bytes.len() * 2,
            };

Should be I think

```rust
            let string_len = match f.precision() {
                Some(max) if self.bytes.len() * 2 > max => max,
                Some(_) | None => self.bytes.len() * 2,
            };
@tcharding
Copy link
Member Author

ooo, (max + 1) / 2 might have been to handle odd length max width, which makes no sense for hex strings. So perhaps this should be

            let string_len = match f.precision() {
                // Do ceil division on max so as to ignore odd length
                // max width which makes no sense for hex strings.
                Some(max) if self.bytes.len() > (max + 1) / 2 => max,
                Some(_) | None => self.bytes.len() * 2,
            };

tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 13, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 13, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
@tcharding
Copy link
Member Author

Sorry for the noise, took me a while to work out the interaction between width and precision - TIL.

tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 13, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 14, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 14, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 14, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 14, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 16, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 18, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 21, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 21, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 21, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
@tcharding tcharding added the 1.0 Issues and PRs required or helping to stabilize the API label Feb 22, 2024
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 23, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
tcharding added a commit to tcharding/hex-conservative that referenced this issue Feb 23, 2024
There are a couple of problems with the width/precision code when we
truncate:

- We are printing one too many hex characters if truncation is odd
- The nested precision code (inside width) is doing the wrong comparison

Includes unit tests to verify the behaviour of the new code.

Fix: rust-bitcoin#70
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.0 Issues and PRs required or helping to stabilize the API
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant