totally-safe-transmute VS base2048

For example, there is this (pure safe Rust) code: https://github.com/ben0x539/totally-safe-transmute/blob/main... which accesses external resources (/proc/self/mem) in order to violate the safety guarantees.

The first is the totally_safe_transmute crate. I mean, who wouldn't love library code that has .expect("welp") and .expect("oof") as its error handling? But that's not even the really scary part. Issue #2 ("i hate this") remains open to this day, but for obvious reasons there's no chance of resolution. This post has some context and a line-by-line explanation of how it works.

You mean like this?

You can also do that in rust on linux: https://github.com/ben0x539/totally-safe-transmute/blob/master/src/lib.rs

I want to correct this statement: Rust can be safer, but not if a library you use contains unsound code. Unsoundness is most often caused by unsafe code, but not always (totally_safe_transmute, anyone?). There is a misconception that unsafe code blocks are always unsound and should be avoided at all costs, but they're completely fine if the safety contracts are upheld. In fact, unsafe blocks isolate the potential issues to make it easier to identify where undefined behavior may be occurring. unsafe code blocks are a feature of the language, and their usage should not be viewed as opting out of any safety the language provides, imo.

Just reimplement totally_safe_transmute in Zig. No need for unsafe.

Why transmute() when you can totally_safe_transmute()?

Well, there is always the totally-safe-transmute.

They should use https://github.com/ben0x539/totally-safe-transmute

qntm did a fun project of using larger bases, constrained to subsets of unicode instead of ASCII like base64. It's specifically for social channels where you're constrained by the number of code points, but not bytes, so you want to maximize data per code point. base2048 is pretty impressive, and base32768 is just absurd.

Numbers don't have to loop until 32k or 2048 (or even up to 1,112,064, until such point the Unicode standard allows for more)

On a semi-related note, they mention base64 encoding messages to evade filters. There were actually other base{n} methods [1] created specifically for Twitter to be more space optimized though not as readily available to operating systems. I guess this is less useful if they are really expanding the text limit to 4k soon but figured I would add it in the event they add a parser for base64.

[1] - https://github.com/qntm/base2048

Actually, in the case of twitter they do some weird counting. It is mostly based on codepoints, true, but some codepoints are considered "heavy" and are counted twice, see https://github.com/qntm/base2048

I know of one case of Twitter doing client side validation [1]. Maybe there are more?

1 - https://github.com/qntm/base2048#note

Base 2048\ (15 comments)