Skip to content

Logging fixes #8250

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

Closed
wants to merge 2 commits into from
Closed

Logging fixes #8250

wants to merge 2 commits into from

Conversation

brson
Copy link
Contributor

@brson brson commented Aug 3, 2013

Updated from #8241

// Truncate the string
let buf_bytes = 256;
let msg = if msg.len() > buf_bytes {
msg.slice(0, buf_bytes) + "[...]"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this make a string of length 257 into one of length 261? (expected behaviour?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it. I don't think it's a problem though. The goal is only to avoid spewing endless garbage - it doesn't need to be precise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On further consideration though, this is probably only appropriate behavior for the console logger, so likely belongs somewhere else. In theory logging can go to arbitrary sinks. Can be fixed in the future. Logging is going to be completely overhauled eventually anyway.

@thestinger thestinger closed this Aug 3, 2013
@thestinger thestinger reopened this Aug 3, 2013
@thestinger thestinger closed this Aug 3, 2013
@thestinger
Copy link
Contributor

Actually landing with #8257.

flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 10, 2022
Fix underflow in `manual_split_once` lint

Hi, a friend found clippy started crashing on a suspiciously large allocation of `u64::MAX` memory on their code.

The mostly minimized repro is:
```rust
fn _f01(title: &str) -> Option<()> {
    let _ = title[1..].splitn(2, '[').next()?;
    Some(())
}
```

The underflow happens in this case on line 57 of the patch but I've changed the other substraction to saturating as well since it could potentially cause the same issue.

I'm not sure where to put a regression test, or if it's even worth for such a thing.

Aside, has it been considered before to build clippy with overflow checks enabled?

changelog: fix ICE of underflow in `manual_split_once` lint
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants