squeek502

Joined 7 years ago

Karma

142

Submissions

Member since

May 30

https://www.ryanliptak.com

View on Hacker News

Recent submissions

Comment · 3 months ago

> a plan to transition to it for C compilation

That's not planned AFAIK (see https://github.com/ziglang/zig/issues/16269). `translate-c` is really only intended for header translation, not C source code.

See https://github.com/ziglang/zig/issues/20875 for the (not fully fleshed out yet) plans around C compilation.

Comment · 5 months ago

Might not make it in time for 0.17 but there is a contributor making progress on the COFF linker: https://codeberg.org/kcbanner/zig/src/branch/coff_linker_wip

Comment · 11 months ago

That would only interact with the shell, as `%` is not actually part of the environment variable name, it's just a way to tell the shell you want it to get the value of an environment variable. The environment block itself is a NULL terminated list of NULL terminated WTF-16 strings of the format <key>=<value>, so `=` would be the more interesting thing to try.

And indeed, it looks like using `=` as a drive letter breaks things in an interesting way:

    =:\> cd bar
    Not enough memory resources are available to process this command.

    =:\bar>

`cd` exits with error code 1, but the directory change still goes through.

With a program that dumps the NULL terminated <key>=<value> lines of the environment block, it looks like it does still modify the environment, but in an unexpected way:

Before `cd /D =:\`, I had a line that looked like this (i.e. the per-drive CWD for C:\ was C:\foo):

    =C:=C:\foo

After `cd /D =:\`, that was unexpectedly modified to:

    =C:==:\

Funnily enough, that line means that the "working directory" of the C drive is `=:\`, and that actually is acted upon:

    =:\foo> cd /D C:

    =:\>

---

You might also be interested to know that '= in the name of an environment variable' is a more general edge case that is handled inconsistently on more than just Windows: https://github.com/ziglang/zig/issues/23331

Comment · 11 months ago

They work just fine, as the drive-specific CWD is stored in the environment as a normally-hidden =<drive-letter>: environment variable which has all the same WTF-16 and case-insensitive properties as drive letters:

    C:\> cd /D λ:\

    λ:\> cd bar

    λ:\bar> cd /D C:\

    C:\> echo %=Λ:%
    λ:\bar

    C:\> cd /D Λ:

    λ:\bar>

Comment · 11 months ago

> Any Mods you create for Minecraft: Java Edition from scratch belong to you (including pre-run Mods and in-memory Mods) and you can do whatever you want with them, as long as you don't sell them for money / try to make money from them

https://www.minecraft.net/en-us/eula

Comment · 1 year ago

0.15.0 was effectively skipped: https://github.com/ziglang/www.ziglang.org/commit/1be0f80b15...

Comment · 1 year ago

Good catch, that does indeed look like a mistake in the spec. Everything past the first sentence of that error description is suspect, honestly (seems like it was naively adapted from the example in [1] but that example isn't relevant to the missing-semicolon-after-character-reference error).

Will submit an issue/PR to correct it when I get a chance.

[1] https://html.spec.whatwg.org/multipage/parsing.html#named-ch...

Comment · 1 year ago

Appreciate it (I'm the author). I'd like to think there's a good bit of interesting stuff in here outside of the specific topic of named character reference tokenization.

Comment · 1 year ago

FWIW here's what that looks like for Zig: https://ziglang.org/news/2024-financials/

Comment · 1 year ago

Relevant: https://github.com/ziglang/zig/issues/4055#issuecomment-1646...

Comment · 1 year ago

As far as I'm aware, using the self-hosted backend for anything other than Debug mode is a goal, but a far-future goal.

I believe the most relevant links are https://github.com/ziglang/zig/issues/16270 and https://github.com/orgs/ziglang/projects/2/views/1?pane=issu... (as you can see, nothing is concrete yet, just vague mentions of optimization passes)

Comment · 1 year ago

I'm probably not describing it fully accurately. See the link for the proper explanation.

Comment · 1 year ago

My understanding is that Zig's incremental compilation will work on a much more granular level (i.e. functions, etc), so, for example, change one function and only that function (and its dependencies) will get recompiled/relinked (there's some linker trickery involved to avoid needing to relink everything IIUC).

More details here: https://ziggit.dev/t/how-zig-incremental-compilation-is-impl...

Comment · 2 years ago

For the miscompilations, the fix wouldn't add a new compile error. Instead, rc.exe would just start doing the right thing in certain scenarios, so previously broken things would start working. For example, padding bytes that were previously missing would get properly added.

It's always theoretically possible that someone, somewhere is somehow relying on such a miscompilation, but for many of the ones detailed in the article, it seems extraordinarily unlikely.

Comment · 2 years ago

I think everything labeled 'miscompilation' could be fixed without breaking backwards compatibility, since triggering them always leads to an unusable/broken .res file. No clue how likely it is they'll be fixed, though.