e4m2

It's very common in games.

Integers are always an option, of course, but in this context it's hard to beat the convenience of just storing seconds in a floating point number.

Related: https://randomascii.wordpress.com/2012/02/13/dont-store-that...

This is a fair concern.

> Does anyone know more about the security of the 8-round form and whether we should be concerned?

This is the latest cryptanalysis I could find (see Table 2 and 3 for an overview):

https://ieeexplore.ieee.org/document/10410840

We don't even have an attack against ChaCha8. While it is likely one will appear as cryptanalysis improves, it is far less likely such an attack will ever become practical.

But obviously, not everyone from within the cryptographic community would agree with JP Aumasson either. For example, DJB had this to say 1 year and 5 months before "Too Much Crypto" first appeared on the IACR ePrint archive: https://twitter.com/hashbreaker/status/1023969586696388613.

So in conclusion; somewhat inconclusive? Going by the results so far, ChaCha8 is probably fine.

The author of that talk, Eric Lengyel, also wrote the book "Foundations of Game Engine Development, Volume 1: Mathematics". Its 4th chapter focuses on the same topics.

The author of the post happens to be the person who implements your crypto, so you don't have to roll your own: https://github.com/FiloSottile.

(I personally also wouldn't use OpenSSL as an example of good cryptographic code)

From the linked GitHub repo:

> As for the heap allocated objects, they will be allocated from unmanged(non-GC) memory, and will be allocated/freed exactly like in Rust.

I understand this decision, but it would also be interesting to see a version of this that hijacks the global allocator and the alloc types to use the GC instead (while still allowing you to opt-out and use unmanaged memory).

Good work nonetheless!

Yes and no.

My post specifically mentions UTF-16 and WTF-16, too. The term "Unicode string" exists and is well established: https://unicode.org/glossary/#unicode_string.

Windows Unicode strings happen to fit this definition, but of course, so would UTF-8 strings. Either way, in Windows's version of reality the definition is narrowed to mean "potentially ill-formed UTF-16LE encoded string", but that doesn't exactly roll off the tongue, so for better or for worse, "Unicode string" is the consistently and widely used Windows-specific nomenclature.

> that release finally made UTF-8 the standard text encoding

This is a bit of a reach unfortunately. UTF-16 (most often broken WTF-16) is still the standard text encoding on NT. The manifest change only makes A-suffixed functions always do a "UTF-8 to UTF-16" conversion, instead of the unhelpful "local codepage to UTF-16" conversion. Sure, that's better, but:

- Microsoft has expressed no interest in switching the actual underlying encoding to UTF-8, they will likely never do so in NT.

- A-suffixed functions only exist for some Win32 API. Newer Win32 functions are defined only taking Unicode strings. All COM, WinRT and native (Rtl/Nt) APIs use Unicode strings as well. The UTF-8 API surface is actually quite small - one might have to step out of the UTF-8 comfort zone in practice.

- Performance is being left on the table. Transcoding still has to be done, it would be more beneficial to at least keep it local for optimization purposes. The most trivial, yet still important use case: constant string conversions can't be optimized across DLL boundaries.

- Unlike, say, DPI awareness mode, there is no official API to change this behavior at runtime. It has to be done through the manifest, a compiler implicitly embedding such a manifest into every executable it produces is not ideal.

TL;DR: It's an improvement, but just barely, so bumping the minimum version just for this "feature" is not worth it IMO. Just bite the bullet and convert to UTF-16 if you have to, it's conceptually simpler and likely faster, too.

It made the switch, sure, but overflow remains undefined.

Why does the stdlib implementation do so badly in the first place?

See also https://arewefastyet.com.

I've done this before, works quite well actually, but isn't very popular for some reason.

> You can do dummy defines of structs with the same size

Don't forget alignment. The general pattern is: https://godbolt.org/z/6je9Yb3rf.

> Does it assume that the predefined capacity will not be reached?

Yes, the function name says exactly that as well, though admittedly what this actually means and what consequences it might have if the assumption is false are probably fairly opaque to a novice user.

> how does it handle the case where you don't have enough capacity to insert the new (k,v) pair?

Breaking the invariant results in safety-checked undefined behavior, that's what the "asserts" in the doc comment signifies[0]. Basically, if something goes awry at runtime you'll get a crash along with a nice error trace in Debug/ReleaseSafe mode or with the appropriate @setRuntimeSafety call.

If instead you'd like to have errors that you can handle, you could use your real allocator where you expect to actually use it and pass a failing allocator[1] everywhere else (but that's sort of abusing the API IMO, I don't know if I'd actually recommend you do this).

[0] https://ziglang.org/documentation/master/#Doc-Comment-Guidan...

[1] https://github.com/ziglang/zig/blob/0dffab7356685c7643aa6e3c...

The core Zig devs, TigerBeetle and Bun are the main ones AFAIK. The latter two are VC backed, the Zig Software Foundation is a 501(c)(3).

Interestingly, the actual syntax tree and related structures/functions are generated from the config.yml file and the templates inside the bin directory. They are using a custom template language written in Ruby, here's an example of how they do enum stringification: https://github.com/ruby/yarp/blob/main/bin/templates/src/tok.... Obviously this isn't a novel idea, but IMO this kind of design goes a long way to support their maintainability argument, especially in C.

Also,

> CRuby actually ships with 90 encodings (as of 3.3)

This is asinine.

True, another extension would be disastrous, we may never recover from the fallout of malformed UCS2-esque UTF-16. Let's just hope no one fixes all the broken, accidentally forward-compatible decoders in the practically infinite amount of time it will take to completely fill the Unicode codespace.

UTF-32 is a fixed-width encoding. To quote directly from the Unicode standard, chapter 3.9, definition 90:

> UTF-32 encoding form: The Unicode encoding form that assigns each Unicode scalar value to a single unsigned 32-bit code unit with the same numeric value as the Unicode scalar value.

UCS-4 is defined in ISO 10646. Before the 2011 revision of the standard UCS-4 had a 31-bit codespace, since then the definitions of the ISO and Unicode standards have converged and UCS-4 and UTF-32 are now synonymous.

> while UCS-4 currently encodes all of Unicode, there's no guarantee it will "forever".

There is. Unicode has a codespace of U+0000..U+10FFFF. There are 2^16 + 2^20 − 2^11 assignable codepoints, in Unicode 15 a total of 149,186 (13.4%) have been assigned.

Even if the Unicode codespace were to ever be extended again (it won't), the only encoding that would become incompatible is UTF-16. In fact, both UTF-8 and UTF-32 are trivially extensible and used to be wider encodings, but were restricted to 0x10FFFF arbitrarily to match UTF-16 limitations.

EDIT: My wording is very ambiguous. There are actually 286,719 (25.8%) assigned codepoints in Unicode 15: https://www.unicode.org/versions/stats/charcountv15_0.html. Still, the point stands.

Since C++20 the correct, constexpr-friendly approach to your specific problem is std::bit_cast: https://en.cppreference.com/w/cpp/numeric/bit_cast.

Frama-C as a bare minimum is a pipe dream.

It's a nice thought, don't get me wrong, but it's hard enough to convince people to add `-fsanitize=...` to their compiler flags. An entire separate static analysis tool with its own learning curve (and its own set of idiosyncrasies) doesn't really qualify for "bare minimum" IMO.

The author of the PR works for Intel, though.

bcrypt has stood the test of time very well. It (unintentionally?) does better than some more modern algorithms which are optimized for the wrong kind of "computational hardness", i.e. cache/memory hard. That being said, to avoid all pertinent issues, it probably should only be used in a construction like: (where `mac` is HMAC, CMAC, the keyed mode of BLAKE etc.)

  mac(bcrypt(mac(password, secret_key)), secret_key)

This has the following caveats:

1) The output of `mac` might need to be encoded in an ASCII-clean way, e.g. using base64, as some implementations don't do well with embedded nulls or 8-bit data.

2) `mac` should produce 72 bytes of data or more. Truncating is better than padding.

3) An appropriate cost should be chosen, 12 or 13 seem to be common choices and should provide a large enough security margin.

There is an extended version on arXiv: https://arxiv.org/abs/2304.05276.

Also, the artifact (Docker image + some guides, CC BY 4.0) for the OCaml library: https://zenodo.org/record/7824835.

Edit: The opam file actually says the license is MIT. I'd be more inclined to believe that over CC BY 4.0 as far as source code licensing goes.

> I don't see how to access move mask from Zig, however.

Bools in a vector each only occupy one bit. You can @bitCast an N element bool vector directly to a uN integer and it will generate movemask on x86.

A lower-level, more security oriented look at some of the same issues: https://googleprojectzero.blogspot.com/2016/02/the-definitiv...

> Can bet 99.99% that Mullvad throws the envelope in the trash and just forgets about it.

Better yet, they shred it: https://mullvad.net/en/help/no-logging-data-policy/#payments.

Yes, in general, having a better router would probably help (although you haven't mentioned the exact model you have, maybe it's already fine and the problem is elsewhere).

Enabling SQM [1] would probably mitigate the issue further, at the cost of requiring more processing power.

[1] https://openwrt.org/docs/guide-user/network/traffic-shaping/...

Ah, good to know! My main sources were the release notes and occasionally your tweets (the account seems to have gotten suspended?), so my information was understandably a bit out of date. Glad to see progress being made though.

> For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?

It's possible, but:

1. The C backend isn't 100% there yet. You won't be able to use all features and might run into bugs.

2. The generated code won't be very readable, it's arguably not too different from just using Zig-compiled object files directly in terms of "opaqueness" and legibility.

If neither of these are a big problem for you (both points are likely to improve with time), then yes, you could do that.

> There are also some things that aren't quite yet finished:

> There are not yet mechanisms to build in release mode (that should be achieved by modifying the toolchain).

> Windows/Mac builds are still in progress; open-source code is mostly tested on Linux.

Source: https://buck2.build/docs/why.

> The main downside is that sometimes your code looks more like Qt and less like Python.

This can be remedied to a degree: https://doc.qt.io/qtforpython/considerations.html#features

The main function returns zero implicitly if control flow reaches the end without encountering a return statement.