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

Lint possible octal escape sequence in string #7981

Closed
hellow554 opened this issue Nov 16, 2021 · 1 comment · Fixed by #8007
Closed

Lint possible octal escape sequence in string #7981

hellow554 opened this issue Nov 16, 2021 · 1 comment · Fixed by #8007
Labels
A-lint Area: New lints

Comments

@hellow554
Copy link
Contributor

What it does

There is this question on Stackoverflow which has the following code:

println!("\033[93mError\033[0m");

and the person (coming with a python background) is confused why Rust doesn't print it colored.
The obvious solution would be to use a crate to do the the work ;)

Categories (optional)

  • Kind: clippy::suspicious

What is the advantage of the recommended code over the original code

Correctly write ASCII escape characters and possible other bytes.

Drawbacks

If you intentionnaly would like to write "\033" this lint would fire. But I doubt that somebody would like to insert a null-byte into their string, so this is probably worth a #[allow(clippy::zzz)]

Example

println!("\033[93mError\033[0m");

Could be written as:

println!("\x1b[93mError\x1b[0m");
@hellow554 hellow554 added the A-lint Area: New lints label Nov 16, 2021
@birkenfeld
Copy link
Contributor

I think this is a very good idea.

I doubt that somebody would like to insert a null-byte into their string

Maybe not for strings, but for bytes literals (which should also be covered by this new lint) null bytes are quite common.

However this is easy to fix: \x00 can be used instead in these cases, which is unambiguous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants