WTF Bites

Gąska

@Gąska It does not allow OS to reclaim freed memory, but that's the case with most other VMs as well.

Both Java and .Net VMs can release unneeded memory to the OS just fine.

Edit: and I'm fairly certain V8 and whatever Firefox uses for JS can do it too. So not being able to do that in WA would be a huge downgrade.

Gąska

@levicki said in WTF Bites:

That smells like NIH syndrome to me thouugh.

Exactly. And WA mandates this design in all browsers.

Zerosquare

Well, "Web development" has always been a polite way to say "NIH syndrome".

dcon

@Zecc said in WTF Bites:

Yes, we've all seen this IKEA lamp before.

Has anyone managed to put it together correctly yet?

LaoC

@JBert said in WTF Bites:

@LaoC There's something I don't understand though : if you are working with Certificate Signing Requests, how come they know the private key? The whole CSR procedure is meant to avoid sending private keys, so wasn't the private key generated on your server then?

EDIT: Just realized that there might be some shitty bussiness-continuity rule in play here where your customer wants to be "in charge" of all key material so they could "transparently" jump ship if they want another service provider.

Yes, they're the ones who create it. The switching-providers argument is certainly one; I'm not sure but I seem to remember there's also some legal requirement or other that when they sign some content with their certified identity that they should actually be in possession of the key, even if someone else does the actual signing

Seems they haven't considered that maybe their secrets aren't really safe if they're going to be handing copies of it anyway (whether or not it happens via a secure channel).

There's just no way to not hand the keys over if you let someone else operate your site. They would be as safe as can be, too, if only they used a secure channel like our upload portal, SFTP or GPG. Hell, I wouldn't even complain too loudly if they used WhatsApp, but unencrypted email is just awful.

TwelveBaud

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

@Gąska It does not allow OS to reclaim freed memory, but that's the case with most other VMs as well.

Both Java and .Net VMs can release unneeded memory to the OS just fine.

Edit: and I'm fairly certain V8 and whatever Firefox uses for JS can do it too. So not being able to do that in WA would be a huge downgrade.

So it turns out I needed to read more of the documentation. Each WebAssembly.Instance of a WebAssembly.Module has its own WebAssembly.Memory. JS must unbox Memory as a fixed-length array. However, both JS and WASM can request an additional multiple of 64KB to be added at any time, and JS can throw an Instance away to reclaim all the memory it has allocated. You can't free from the WASM side though, and JS can't shrink an existing Memory, only make sure it and all the WASM code that uses it get GCed.

Gąska

@TwelveBaud it feels like WAsm was designed in its entirety by one weirdo in like 10 days.

Tsaukpaetra

@dcon said in WTF Bites:

@Zecc said in WTF Bites:

Yes, we've all seen this IKEA lamp before.

Has anyone managed to put it together correctly yet?

Sorry, I've been busy with this 3-d hash object and it's slightly higher priority.

Zerosquare

@Gąska said in WTF Bites:

@TwelveBaud it feels like WAsm was designed in its entirety by one weirdo in like 10 days.

So? That's how JS was created in the first place, and look how successful it has been!

Mason_Wheeler

@Zerosquare

Zecc

@Gąska said in WTF Bites:

@TwelveBaud it feels like WAsm was designed in its entirety by one weirdo in like 10 days.

@Tsaukpaetra said in WTF Bites:

Sorry, I've been busy with this 3-d hash object and it's slightly higher priority.

:)

Bulb

@LaoC said in WTF Bites:

There's just no way to not hand the keys over if you let someone else operate your site.

It's a pity that the name constraints standard extension is not universally supported—or at least was not.

If it worked, the company could be given an intermediate CA restricted to their domains, which they would not transfer anywhere, just use it to sign the server key, that would be generated by the hosting provider on the server and never transferred anywhere either. So if they changed providers, or even the server needed reinstalling, they'd just sign a new key, which would be easy, and no key material would have to be transferred to anybody.

Per this comment the extension is supposed to work on OS X and iOS since some time last year—is there anybody with a Mac around who is not to check?

Bulb

@Gąska said in WTF Bites:

@TwelveBaud it feels like WAsm was designed in its entirety by one weirdo in like 10 days.

WAsm was designed so that they could get something to work now and then evolve it, because if they wanted to make it perfect first, they'd never get around to ship anything. And note that ~~four~~three¹ different parties have to implement it to be actually usable, so they can't add features that fast.

So proper heap management is probably on the roadmap somewhere just like garbage collection is. They just didn't get there yet.

After all, JVM might be releasing memory back to system properly now, but it didn't do so from the first release either.

Gąska

@Bulb said in WTF Bites:

So proper heap management is probably on the roadmap somewhere just like garbage collection is.

Having OOTB garbage collection sounds like a nice way of defeating the entire purpose of WAsm.

dkf

@Bulb Generally speaking, either a memory allocator uses a pool that doesn't release memory back to the OS (though it can page things out, so this isn't terrible) or it only releases larger blocks back (eg, if you allocate a 1MB chunk for an image, that can be released efficiently, but a bunch of 24 byte chunks probably won't ever get returned because the page they're on is likely to still be in use). In theory, garbage collectors can coalesce small chunks so more pages can be freed... but nobody does that much any more because it is hard to implement correctly and really slow.

And yes, I have done work at that level. It's pretty miserable to debug.

Bulb

@dkf Normal malloc usually releases everything that is a page or lager. But getting memory by page wouldn't be efficient for a collector and compaction usually only happens when copying from the 0th generation, with the 1st generation usually being permanent, so, yes, unlikely to ever return anything (except big buffers) anyway.

dkf

@Bulb Big allocs are totally returnable. Small ones, no. Also, big allocs are the ones you can probably recover from failing to allocate. Well, some of the time anyway. Failed small allocs tend to be fatal.

Zecc

@levicki

Path.Combine(@"C:\ould", "/be", " worse")

Rhywden

Small WTF of my day: So, we've got a bunch of HP SlimLine desktops at my school (currently around 60) to serve as light Office machines. 30 of those reside in one lab for my Data Processing course (y'know, Word, Excel, PowerPoint). Said course is kind of a parforce run through the Office programs but I digress.

Some of those machines have developed an annoying habit: They don't turn on. At least not without coaxing:

Sometimes the power LED lights up but nothing further happens. This can be solved by pulling the power plug for about 10 seconds, plugging it back in and presto!
And sometimes nothing happens at all, though, after pressing the power button. You then have to pull the plug for several minutes after which things work again (though you may be greeted with a CMOS checksum error - a reset to defaults creates no further issues, however).

This lead me to the HP support site where I was first supposed to create a ticket (y'know, type in all relevant info) and, upon obtaining the ticket number, call tech support.

Did all that and got "Unavailable" as the ticket number. Great! Furthermore, the telephone line used one of those robots whose job it was to spell out all the options in the slowest manner possible. But I persevered and finally got a human.

Who then managed a feat of astounding cognitive dissonance by telling me that he couldn't say whether it was software, hardware or the lunar cycle causing this - but that the PCs in question needed to be replaced regardless.

Thus fobbing me off on our supplier. Yeah, should've know better.

TimeBandit

@Rhywden said in WTF Bites:

you may be greeted with a CMOS checksum error - a reset to defaults creates no further issues

This usually means the CMOS battery is dead, which can cause all kind of issues IME

Rhywden

@TimeBandit Yeah, but it's about 8 of them showing these issues and they're about 8 months old.

TimeBandit

@Rhywden said in WTF Bites:

they're about 8 months old

Vixen

@levicki said in WTF Bites:

string WhatTheFuck = Path.Combine("C:", "This/Is/Insane");
Anyone care to guess the result?

assuming C#.....

C:\This/Is/Insane which when fed into a file open/create call throws an exception because invalid filename.

topspin

@levicki said in WTF Bites:

string WhatTheFuck = Path.Combine("C:", "This/Is/Insane");
Anyone care to guess the result?

My guess is C:\Users\Levicki/This/Is/Insane.

And no, that's a legitimate guess, not a joke at your expense. Even if it works well.

cvi

@levicki said in WTF Bites:

This behavior is not pointed out anywhere in the documentation, and they also note that they don't check for all invalid characters and by checking the examples you can see that the method Combine doesn't even produce a combination of elements you pass in all the time -- sometimes it picks one and sometimes the other when the elements conflict instead of throwing an error.

They talk about it in some general section about windows paths, probably here (Naming Files, Paths, and Namespaces). See "Fully Qualified vs Relative Paths".

Essentially, Windows keeps track of a current working directory per drive (as well as a current drive). If you say "foo\bar", it looks for "foo\bar" in the CWD of the current drive. If you say "C:foo\bar", it looks for "foo\bar" in the CWD of drive C. If you say "\foo\bar", you look for a file "bar" in a directory "foo" in the root of the current drive.

From a Win32 path point of view it makes total sense. Whether or not Win32 paths make sense is a different question. (IMO, the whole drive letter thing can DIAF already. Actually, since we're at it, Win32 paths can DIAF more generally.)

hungrier

@levicki said in WTF Bites:

for some reason Microsoft decided that combining C: and whatever should result in C: being substituted with current working directory of that drive.

As a point of interest, I tried the code in an online dotnet thing and it resulted in C:This/Is/Insane (no path separator after the C: drive).

hungrier

@levicki I figure they must be doing some kind of non-standard magic to get it to chooch, but it claims to be .net 4.7.2. Taking a quick look around I wasn't able to find any technical details but if you like you can investigate it: https://dotnetfiddle.net

But yes, I was expecting a path separator at minimum, regardless of what other potential insanity it could have.

topspin

@levicki said in WTF Bites:

@topspin said in WTF Bites:

And no, that's a legitimate guess, not a joke at your expense. Even if it works well.

You win the prize -- for some reason Microsoft decided that combining C: and whatever should result in C: being substituted with current working directory of that drive. For me that is insane behavior.

It sure is, but it’s always worked that way, so the chance of this getting changed is approximately zero.
Even if nobody expects this.

I expect Path.Combine to combine strings (like it says in the documentation) while validating characters and adding / or \\ as necessary, not perform substitutions, however valid they might appear in the context of backward compatibility.

From its perspective, it “combines” the absolute path of "C:", which fully qualified is called "C:\Users..." (or whatever the CWD is), with the relative parts you passed in. See @cvi's post.
Otherwise you could just use the string concatenation operator.

My advice? Don't use, ever.

Just make sure to use C:\ instead, that should work as expected.

topspin

@hungrier said in WTF Bites:

@levicki said in WTF Bites:

for some reason Microsoft decided that combining C: and whatever should result in C: being substituted with current working directory of that drive.

As a point of interest, I tried the code in an online dotnet thing and it resulted in C:This/Is/Insane (no path separator after the C: drive).

Probably just means the current directory is the root directory?

Zerosquare

dotnet-bot

Path.Combine Method (System.IO)

Combines strings into a path.

This method assumes that the first argument is an absolute path and that the following argument or arguments are relative paths. If this is not the case, and particularly if any subsequent arguments are strings input by the user, call the Join or TryJoin method instead.

C: is not an absolute path, as explained by @cvi, so that's the wrong function to use.

I wouldn't say this is intuitive, but it's documented, and the way C:something is parsed dates back to the days of DOS.

TwelveBaud

@levicki @hungrier Path.Combine() returns "C:This/Is/Insane". (So Hungrier's right.) But if you pass that to anything that canonicalizes the file name, such as Path.GetFullPath(), that'll do the substitution that leads to @"C:\Users\%USERNAME%\This\Is\Insane". (So Levicki's right too.)

Jaloopa

@topspin said in WTF Bites:

@levicki said in WTF Bites:

@topspin said in WTF Bites:

And no, that's a legitimate guess, not a joke at your expense. Even if it works well.

You win the prize -- for some reason Microsoft decided that combining C: and whatever should result in C: being substituted with current working directory of that drive. For me that is insane behavior.

It sure is, but it’s always worked that way, so the chance of this getting changed is approximately zero.
Even if nobody expects this.

I expect Path.Combine to combine strings (like it says in the documentation) while validating characters and adding / or \\ as necessary, not perform substitutions, however valid they might appear in the context of backward compatibility.

From its perspective, it “combines” the absolute path of "C:", which fully qualified is called "C:\Users..." (or whatever the CWD is), with the relative parts you passed in. See @cvi's post.
Otherwise you could just use the string concatenation operator.

My advice? Don't use, ever.

Just make sure to use C:\ instead, that should work as expected.

Reminds me of the weirdness I've seen with HttpClient. Combining a base address with a relative address, you need to have one specific combination of ending and starting slashes between the two, which I never remember and isn't explicitly documented

dkf

@Jaloopa said in WTF Bites:

Reminds me of the weirdness I've seen with HttpClient. Combining a base address with a relative address, you need to have one specific combination of ending and starting slashes between the two, which I never remember and isn't explicitly documented

There are W3C rules for how URL absoluting is supposed to work. Which isn't to say that HttpClient necessarily gets it right, but I'd think someone would've noticed if it was wrong (as it would have been a security hole). But the base URL must be absolute for things to work.

PleegWat

@dkf Maybe he means like in apache configuration where I'm pretty sure the following all mean different things:

Alias /foo  /bar
Alias /foo/ /bar
Alias /foo  /bar/
Alias /foo/ /bar/

Tsaukpaetra

@levicki said in WTF Bites:

string WhatTheFuck = Path.Combine("C:", "This/Is/Insane");
Anyone care to guess the result?

c:\Windows\System32\This/Is/Insane

What, don't you run as root?

hungrier

@Tsaukpaetra said in WTF Bites:

What, don't you run as root?

A few years ago I worked on a short term contract for another company, and all of the commits from one of the lead devs were signed "root"

Whether that means he was actually using his computer as root, or if he just put that for fun, is unknown

Benjamin Hall

@levicki Aren't you supposed to use the filesystem APIs for such things (ie not work with directly-entered-by-the-user paths as strings)? I know in "modern" windows development in C# it's really really hard to open an arbitrary file outside the program's bundle, and even within the bundle you're supposed to use the various APIs that abstract such things and only deal with relative paths. Because your files may not be where you expect them to be (directory virtualization and all that). It seems what you're trying to do is the same sort of thing that caused there to be directory virtualization (the whole ~/APPDATA mess + the various Program Files directories and the resulting weirdness) in the first place.

dcon

@TimeBandit Made in China. 10 years ago.

dcon

@levicki said in WTF Bites:

I'd expect a directory separator to be added

I wouldn't - because that changes the path. (from relative to absolute)

hungrier

Browsershots

Apparently we're an adult or gambling site:

TimeBandit

@hungrier said in WTF Bites:

Apparently we're an adult or gambling site:

Yes

https://what.thedailywtf.com/topic/26247/instagram-is-linkedin-for-sluts/

hungrier

@TimeBandit What's weird is it worked a few months ago, when I was testing out some SVG rendering cross-platform.

What if it's my fault, maybe they thought Minesweeper was gambling

Pockets

Have you ever wondered "What would happen with an industry of only '10x Rockstar Developers'?"
The answer is Data Science.
Fuck my life.

topspin

@hungrier said in WTF Bites:

Browsershots

Apparently we're an adult or gambling site:

The Daily Worse Than Failure

topspin

@Pockets said in WTF Bites:

Have you ever wondered "What would happen with an industry of only '10x Rockstar Developers'?"
The answer is Data Science.
Fuck my life.

Is this... ironical?
Please elaborate.

TimeBandit

@Pockets said in WTF Bites:

What would happen with an industry of only '10x Rockstar Developers'?

Easy: the only game available would be GTA

Mason_Wheeler

@hungrier said in WTF Bites:

@Tsaukpaetra said in WTF Bites:

What, don't you run as root?

A few years ago I worked on a short term contract for another company, and all of the commits from one of the lead devs were signed "root"

Whether that means he was actually using his computer as root, or if he just put that for fun, is unknown

Either that, or the hacker from Person of Interest was in your system...

Mason_Wheeler

@Benjamin-Hall said in WTF Bites:

"modern" windows development in C#
the program's bundle

Pockets

@TimeBandit said in WTF Bites:

@Pockets said in WTF Bites:

What would happen with an industry of only '10x Rockstar Developers'?

Easy: the only game available would be GTA

No, Red Dead Redemption. Got to have the Cowboys.

Benjamin Hall

@levicki said in WTF Bites:

@Benjamin-Hall said in WTF Bites:

Aren't you supposed to use the filesystem APIs for such things

I am making a program where the base path comes from the registry (i.e. I don't control it), and the remaining part comes from a hierarchy inside a user-selected ZIP file. It is basically a tool which will scan the ZIP and given the base path locate and delete those files on the disk. I thought Path.Combine should be safe enough for that use case but it tuns out I might have been wrong.

Not sure which filesystem APIs you have in mind though. Care to elaborate? Also it would be nice if you don't jump to conclusions and accuse me of being part of the problem.

Looking at your intended case, it seems the APIs I was thinking of (which, now that I look more into it, were focused on Windows Store apps with their "special" behaviors) aren't what you need. I'm sorry for casting aspersions.

But testing it out in VS2019, under .NETCore3.0 gave what I would completely expect here:

using System;
using System.IO;

namespace DirectoryTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string docPath = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
            var diTop = new DirectoryInfo(docPath);

            var directories = diTop.EnumerateDirectories("*");
            foreach (var di in directories)
            {
                Console.WriteLine($"{Path.Combine("C:",di.Name)}");
            }
           
            Console.WriteLine($"{Path.Combine("C:","path/to/foo")}");
        }
    }
}

Using the directory enumeration or testing it with a manually-generated string (which has the wrong slashes as written, but which PowerShell accepts just fine as a path) produces exactly what I would expect and not what others were saying above.

I get C:\path/to/foo, which powershell accepts just fine as a path (assuming that directory exists). So now I has a confused.