rust-base64
getopt
rust-base64 | getopt | |
---|---|---|
9 | 7 | |
573 | 97 | |
- | - | |
7.3 | 0.0 | |
about 1 month ago | 10 months ago | |
Rust | C | |
Apache License 2.0 | The Unlicense |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rust-base64
- Rust is not the language for you if you don't like traits
-
Base64 Implementation in Rust
It would be interesting to compare your implementation and the most popular implementation for Rust+base64: https://github.com/marshallpierce/rust-base64
- Rust-base64: restore {encode, decode} convenience functions
-
Question in Rust about Base64 encoding for xmlrpc
I am writing a CLI util in rust that utilizes xml-rpc-rs to talk to an rtorrent server and I would like to be able to add torrent files. OK according to the python implementation, which some of the rtorrent developers have said is good, of xmlrpc-client it uses this base64 format: https://datatracker.ietf.org/doc/html/rfc2045.html#section-6.8 I base64 encode /some/file/foo.torrent and send it up. OK!
-
Announcing uuid-simd, hex-simd and base64-simd!
Funny that you claim base64 forbids unsafe code while linking a PR where the current maintainer of the crate explicitly agrees that unsafe for the purpose of SIMD-acceleration is a-okay. Did you by any chance meant to link https://github.com/marshallpierce/rust-base64/pull/114 instead? ;)
-
Fast Rust Builds
> It does need to be in the standard library
When I say that something “has to be in the standard library”, I mean that it can’t be implemented outside the standard library. That’s certainly not the case here. You’re using an outright bad definition of “need” here—subjective opinion rather than objective requirement.
> because everyone needs it
This is factually wildly wrong. I wrote a fair bit more here but decided it wasn’t helpful. Précis: web stuff tends to load it indirectly (though amusingly most of the time actually not use it, so that Base64 code won’t actually end up in your binary), but it’s not terribly common outside of internet stuff to reach for Base64.
I’ll leave just one more remark about Base64: once things are in the standard library, breaking changes can no longer be made; the base64 crate is still experiencing breaking changes (<https://github.com/marshallpierce/rust-base64/blob/master/RE...>, 0.12 and 0.13 were last year and 0.20 is not released), largely for performance reasons.
Please don’t just call the thin-std approach “problematic” without acknowledging that the alternative is at least as problematic, just with a different set of caveats.
-
Stable versions of most important community crates
Many of these have their own tracking issues on the path to v1.0. For example see this one for base64.
-
Debian discusses vendoring again
I see base64. If the standard library has base64 encoding, go ahead and use it. But as a third-party dependency? Again, base64 encoding and decoding is trivial. I've written this a few times myself. It's not worth a dependency.
getopt
-
Porting my very simple C code from Unixen/macOS to Windows
Between -std=c99 and removing these headers, you're missing time definitions (struct timeval, gettimeofday) and option parsing definitions (struct option, getopt_long). Mingw-w64 provides all this for compatibility, but MSVC has none of these, so you'll need to write replacements. I've written embeddable, public domain implementations of getopt and something like getopt_long, in case that helps. These are how I deal with option parsing portability.
-
I recently made a simple project in C. Would be really helpful if someone could review my code.
The option parser is crude and doesn't follow conventions. Particularly the lack of -- support (disables option parsing) would make it impossible to use safely in scripts. If you don't want to use the system or toolchain-provided getopt, here's a public domain, embeddable implementation: getopt.h
-
How to properly handle position non-specific program arguments? ./my_prog --format:"mp3"
On unix-like systems there's a getopt function for parsing short options. Mingw-w64 has one as well, to cover Windows programs. If I care about portability, I just embed my own so it not only works everywhere, it behave the same everywhere, too.
- How to make programs for linux
-
[ Feed back wanted ] Is this a good way to handle lot of if instead of if else?
https://github.com/skeeto/getopt/blob/master/getopt.h (short)
-
Debian discusses vendoring again
Not only the GNU, you have an example in this thread where someone suggested to use or roll something similar to https://github.com/skeeto/getopt/blob/master/getopt.h, which, surprise, depends on strchr, a function that solves a much trivial problem than POSIX getopt, to begin with.
What are some alternatives?
unicode-xid
optparse - Portable, reentrant, getopt-like option parser
itoa - Fast integer to ascii / integer to string conversion
cargs - A lightweight cross-platform getopt alternative that is tested on Linux, Windows, FreeBSD and macOS. Command line argument parser library for C/C++. Can be used to parse argv and argc parameters.
portable-simd - The testing ground for the future of portable SIMD in Rust
rust-fnv - Fowler–Noll–Vo hash function
ulid-rs - This is a Rust implementation of the ulid project
perl5 - 🐪 The Perl programming language
abseil-cpp - Abseil Common Libraries (C++)
ripgrep-all - rga: ripgrep, but also search in PDFs, E-Books, Office documents, zip, tar.gz, etc.
uuid - Generate and parse UUIDs.
itoa - Fast function for printing integer primitives to a decimal string