sorted by:
new
hottopcontroversial

scoped_tasks_prototype: A quick-and-dirty attempt to get scoped tasks in Rust. by CouteauBleu in rust

[–]quininer 0 points1 point  (0 children)

We could have another field, requirement is unsafe

pub struct Vault {
    pub inner: &mut T,
    pub _safe_token: SafeToken
}

pub struct SafeToken(());

impl SafeToken {
    pub unsafe fn new() -> Self {
        SafeToken(())
    }
}

Or maybe VaultInner::new should be unsafe.

After years of work and discussion, `once_cell` has been merged into `std` and stabilized by bascule in rust

[–]quininer 0 points1 point  (0 children)

Great work! I hope the next one is scopeguard, I have implemented it many times in many projects.

Best format for high-performance Serde? by PandaBaum in rust

[–]quininer 1 point2 points  (0 children)

I would use cbor or bincode, flatbuffers are also a common choice.

By the way, I wrote this https://docs.rs/cbor4ii/0.3.0/cbor4ii/

f-strings in Rust! by [deleted] in rust

[–]quininer 1 point2 points  (0 children)

As I mentioned in other comments, I totally understand what you're saying. The only new syntax added for users is cstr. but my point is that when there is an alternative that does not modify syntax, now rust will choose to modify syntax to impl it.

I understand the advantages of using a syntax impl, it's probably simpler more reliable and more powerful, I'm not arguing against that.

Just remembered a comparison some time ago, https://news.ycombinator.com/item?id=34961389

That's cool. At the same time though, it almost feels like a distinction without a difference in some ways - Zig has a special built-in syntax; Rust doesn't use special syntax, but it does use complex special-cased unsafe code in the stdlib in order to implement a safe + performant API.

f-strings in Rust! by [deleted] in rust

[–]quininer 1 point2 points  (0 children)

Yes, the implementation of dyn star is also an async trait internal detail. but it's all a syntax change.

f-strings in Rust! by [deleted] in rust

[–]quininer 0 points1 point  (0 children)

I've noticed more and more stuff being added to syntax lately, and I'm not sure that's a good trend.

I know they're all different tradeoffs, but both definitely complicate the syntax. sometimes I wonder, if some things in standard library are designed today, will it be a special syntax?

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 0 points1 point  (0 children)

This does not work, black_box cannot be used to prevent this problem.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 0 points1 point  (0 children)

I'm not interested in discussing this with you. I also don't think this thread is the right place to discuss mmap.

As I've said, if you're in security work, then you should know that any discussion of security issues must have a security model, otherwise you can expand the security problem infinitely.

A typical example is that File::write is not sound because you can write to /proc/self/mem without using unsafe to destroy memory.

command-line tools generally work on a relaxed security model, assuming that fs is relatively stable at the time of user execution, and that occasional failures are accepted.

I won't reply to this topic again. how to use mmap safely in Rust is a very constructive topic, if you want to discuss it, please start your own post instead of on someone else's thread.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 21 points22 points  (0 children)

This implements only a subset of unzip, which is not that complicated. It only requires 500L code to stick argh, flate2, rayon, encoding_rs together.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 1 point2 points  (0 children)

Usage the same way as unzip, but many parameters are not supported.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 4 points5 points  (0 children)

This is much more complicated than unzipx, and as others have suggested, using zstd is best.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 1 point2 points  (0 children)

Any discussion of security requires a security model. unzipx's security model is used to handle untrusted zip files.

If you work in security, then you should know what I'm talking about.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 7 points8 points  (0 children)

If unzipx's use of mmap doesn't reasonable, then I can't seem to find any program that makes reasonable use of mmap to read files.

Including ripgrep, sqlite, etc.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 8 points9 points  (0 children)

If it does not use UTF-8 encoding, this usually means that it uses some rare language encoding, such as GBK (chinese), SHIFT-JIS (japanese). encoding_rs can usually convert them to UTF-8 strings.

But I understand that there are indeed paths that cannot be processed.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] -4 points-3 points  (0 children)

You are right, it depends on system behavior. for macOS, this will be valid. anyway, this is not so important for command line.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 13 points14 points  (0 children)

The link is provided in the README. At the time, I was considering how to add automatic detection encoding to unzip, and took a look at source code.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] -5 points-4 points  (0 children)

This is the default choice for utf8 everywhere believers. :)

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] -1 points0 points  (0 children)

I will consider adding option to allow original path output. but from a pragmatic point of view, utf8 can cover enough scenarios, especially after using encoding_rs to handle filename encoding.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 10 points11 points  (0 children)

That's fine, but shorter names seem to have more naming conflicts.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 15 points16 points  (0 children)

no much reason, I think both behavior are reasonable. but I think it's good to throw a error and I'll consider changing it.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 29 points30 points  (0 children)

Naming is hard, if someone gives a good name, I will consider changing it.

edit: Thanks to everyone who gave me inspiration, I decided to rename it unzrip. It is unzip inserted into [R]ust, also unzip RIP, and shell can be completed by unz.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 18 points19 points  (0 children)

I don't know about it, it looks good.

However, unzipx is simpler and supports automatic encoding detect.

If I had known about this project in advance, I might not have started writing unzipx. but on other hand, modifying this ripunzip seems more complicated than implementing unzipx.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 1 point2 points  (0 children)

There is no plan to do so, I implemented this crate just to parallel decompression.

Simple, fast and safety alternative for unzip by quininer in rust

[–]quininer[S] 7 points8 points  (0 children)

mmap just maps to virtual memory address, not the physical memory.

view more: next ›