ChrisSD

This has actually changed a bit in the last few years. In Windows 11 writing to `.\CON` will write to the file but writing to `CON` will still write to the console.

Imagine, for example, there's a really interesting scientific paper someone would love to talk about but it's in the field of Climate Science. Everyone knows the comments a blog post on it is going to get. And they're (almost) all going to be the same no matter what the paper is actually about. Every time.

Should someone feel they have to self-censor just to avoid this?

But our local "system" has a gigantic miasma of incandescent plasma on our doorstep. The Earth itself should not need to worry about entropy for a long while yet...

We're talking about default fonts that were last changed 15 years ago. 15 years between jobs isn't going to provide job security for an industry.

The ucrt is included as far back as Windows 7 (if you install updates).

There are two things here. The `unsafe` in an `unsafe { ... }` block is referring to the contents of the block. From the outside it is indeed safe to use as if it were safe code. No special requirements necessary. So, yes, from a certain point of view `safe` would have been a better name (albeit confusing in a different way).

An `unsafe fn` however does need to be used correctly (and should document those requirements). However, these can only be called within `unsafe` blocks, so see above.

Personally I think what people do in their free time is up to them, so long as it isn't hurting anyone. I don't think it's right for you to police that.

Your phrasing is interesting: "visible drama". Which suggests it would be "better" for Rust if it covered these things up :). Obviously that would be hard to do at the moment. It's actions are fairly open and there is a very keen interest in "drama" from everyone from HN to popular YouTubers who can boost the signal.

Personally I think some amount of immediate drama is necessary to force positive change. Better than many orgs that keep this kind of thing behind closed doors (and somebody maybe writes a blog post about it years later).

Tbh, all I recall about pocket is it showed me a load of random content which I had no interest in, which felt spammy. And I think it needs a login for some reason? It certainly looked and felt like an external addon rather than a built-in thing.

If it had just been a reading list I'd have been much more interested.

> (mainly because it would add ~30% more methods to Vec?)

Sort of. Rather than bolting on fallible methods adhoc to an existing type, it was felt it would be better to take a step back and actually design this properly. This includes third party crates experimenting with different options.

Maybe we should have a FallibleVec type? Maybe common vec-like methods could be abstracted out in to a `RawVec` type? Maybe both? Maybe the (unstable) `Allocator` API could be adapted to better suite all these cases? Whatever the case it's not great to be adding on a ton of methods in the heat of the moment.

core is part of the language (or at least, many parts of it are).

The way that rustc currently splits this up is an implementation detail of rustc, not something that must be copied exactly. Rust without core is not Rust. It's not even usable.

Hm... I'm not sure I understand. Why would you expect no_core to be specified? It's an implementation detail of rustc, not part of the language.

No, not really. It only supports "normal" win32 paths. You would have to mount it to a drive letter or directory.

You can now use ".\COM1" or "COM1.txt" but not a bar COM1.

I think what's missing from this discussion is an emphasis on how layered Windows paths are.

The Win32 paths are like an emulation layer. They parse the given path and produce a kernel path. Win32 implements all the weird history you know and love as well as things like `.` and `..`. You can use the `\\?\` prefix to escape this parsing and pass paths to the kernel.

The NT kernel has paths like `\Device\HarddiskVolume2\path\to\file`. NT paths are much simpler. There are no restrictions on paths except that they can't contain empty components (notably they can contain nul). At this layer, `.` and `..` are legit filenames.

However, it's the filesystem driver ultimately says what's a valid filename and what isn't.

There are some APIs that have a lower limit than 260. But the limits can be bypassed using `\\?\` prefixed paths (except when using SetCurrentDirectory) or by enabling long paths https://learn.microsoft.com/en-us/windows/win32/fileio/maxim...

This has actually changed in Windows 11. You can use "con.html" without fear. "con" is still a bit of a problem. ".\con" will work but not a bare "con".

Yes you can create files named `.` and `..`. However, any sensible filesystem driver will reject that name (spoiler: there does exist drivers that aren't sensible).

A stream name is somewhat more limited than that:

> All Unicode characters are legal in a streamname component except the following:

> * The characters \ / :

> * Control character 0x00.

> * A streamname MUST be no more than 255 characters in length.

>

> A zero-length streamname denotes the default stream.

https://learn.microsoft.com/en-us/openspecs/windows_protocol...

> There is no "current directory" on an UNC share

SetCurrentDirectory allows setting the current directory to a UNC share. https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

> Also wrong, it's not the command line shell that keeps track of the current directories, it's the Windows kernel itself. But I agree that such a scenario is quite useless as you can never be quite sure on what CWD you are on a given drive

Not for a long time. It's set as a special (hidden) environment variable like `=C:=C:\current\directory`. https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14...

Some variation on this has been consistently brought up for going on a decade now. At this point it's a HN meme.

Its opposite is "cargo culting".

I'd also emphasise that fortunately most modern cryptography (outside of one time pads) does not rely on truly random numbers. So long as the sequence is unpredictable enough it's fine (i.e. you can't use known values to more reliably guess unknown values).

The PRNG in the linked page isn't very good but in general PRNGs are super useful in the real world even if they aren't truly random, just so long as they have some source of entropy to occasionally mix into the PRNG.

The bit after `>` is a quote, not my words. See https://en.cppreference.com/w/c/language/array for the source

It's saying that C99 implemented flexible array members but before then some compilers introduced their own (nonstandard) implementation of flexible array members, using the (not allowed) zero sized array notation.

According to the C spec, zero length arrays are explicitly illegal.

> Zero-length array declarations are not allowed, even though some compilers offer them as extensions (typically as a pre-C99 implementation of flexible array members).

However, as they say, gcc (and therefore clang) have an extension that allows it. So does MSVC but it works slightly differently.

Kind of:

> If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned to indicate an error, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object

So it may actually allocate (although the allocation is unusable).

> Even if you configure your account with 1,000,000 iterations, a compromised Bitwarden server can always tell the client to apply merely 5,000 PBKDF2 iterations to the master password before sending it to the server. The client has to rely on the server to tell it the correct value, and as long as low settings like 5,000 iterations are supported this issue will remain.

This seems like a serious flaw that completely undermines setting a custom value, no? If an attacker gets temporary control of a bitwarden server then they can get your password in a more easily crackable form no matter what you set.

It was designed as a security feature but it's been coopted to block competitors (or anyone else the CEO takes a personal disliking to). Therefore calling it an "anti-Mastadon" filter is accurate in this context, no matter the specifics of how that filter is currently implemented.

Just to clarify further, note that actually preserving the "as if" behaviour does involve some complexity in the implementation. E.g. appending to WTF-8 has to be handled carefully to ensure it remains truly the same as doing so with WTF-16. This is because any newly paired surrogate has to be converted to its proper UTF-8 encoding. Similarly splitting WTF-8 can potentially break apart what was valid UTF-8 (though I'm not totally convinced that there's a good use case for actually doing this, at least for Windows paths).

Of course the implementation details are something that can and should be handled by a library instead of doing it manually.

It does simplify things in places. One thing that isn't covered is that a code point is not necessarily a letter or vice versa. E.g. a single letter/symbol/emoji/whatever can be made up of multiple code points. So it isn't quite true that one "platonic" letter is one code point (it may or may not be).

Windows NT uses actual Unicode under the hood (originally UCS-2, now UTF-16).

Windows NT started development in 1989 and was released in 1993. Considering the Unicode standard was first published in 1991/2, I think Windows NT can be counted as an early adopter.