squeek502
Re:Zig's Incremental Compilation Internals
on Tuesday July 28, 2026 @02:33PM (#49088036)
> 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.
Re:Zig ELF Linker Improvements Devlog
on Saturday May 30, 2026 @07:36PM (#48341649)
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
Re:Windows drive letters are not limited to A-Z
on Sunday November 30, 2025 @11:31PM (#46103497)
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>
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
=C:==:\
=:\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
Re:Windows drive letters are not limited to A-Z
on Sunday November 30, 2025 @02:03PM (#46099379)
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>
Re:Roblox is a problem – but it's a symptom of something worse
on Tuesday November 25, 2025 @03:24PM (#46050310)
> 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
Re:Zig 0.15.1 Release Notes
on Wednesday August 20, 2025 @03:44PM (#44965597)
0.15.0 was effectively skipped: https://github.com/ziglang/www.ziglang.org/commit/1be0f80b15...
Re:Slightly better named character reference tokenization than Chrome,...
on Friday June 27, 2025 @07:00PM (#44401071)
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...
Re:Slightly better named character reference tokenization than Chrome,...
on Friday June 27, 2025 @04:00PM (#44399786)
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.
Re:Zig Devlog: Self-Hosted x86 Back End Is Now Default in Debug Mode
on Monday June 09, 2025 @07:42AM (#44223446)
FWIW here's what that looks like for Zig: https://ziglang.org/news/2024-financials/
Re:Zig Devlog: Self-Hosted x86 Back End Is Now Default in Debug Mode
on Monday June 09, 2025 @02:33AM (#44221912)
Re:Zig Devlog: Self-Hosted x86 Back End Is Now Default in Debug Mode
on Monday June 09, 2025 @02:23AM (#44221856)
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)
Re:Zig 0.14.0 Release Notes
on Thursday March 06, 2025 @09:48PM (#43287043)
I'm probably not describing it fully accurately. See the link for the proper explanation.
Re:Zig 0.14.0 Release Notes
on Wednesday March 05, 2025 @05:01PM (#43273244)
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...
Re:Every bug/quirk of the Windows resource compiler (RC.exe), probably
on Sunday October 13, 2024 @07:34PM (#41832702)
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.
Re:Every bug/quirk of the Windows resource compiler (RC.exe), probably
on Sunday October 13, 2024 @06:22AM (#41826745)
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.
Re:Every bug/quirk of the Windows resource compiler (RC.exe), probably
on Sunday October 13, 2024 @06:17AM (#41826716)
See https://www.ryanliptak.com/blog/zig-is-a-windows-resource-co... for an example of using the Zig build system to cross-compile an existing Windows GUI program written in C from any supported host system.
Re:Every bug/quirk of the Windows resource compiler (RC.exe), probably
on Sunday October 13, 2024 @01:16AM (#41825351)
Apologies if I got the tone wrong there, I definitely wasn't trying to roast the other projects.
In terms of what I prioritized bug-for-bug compatibility on, I tailored it to getting https://github.com/squeek502/win32-samples-rc-tests passing 100%, and then also tried to take into account how likely a bug/quirk was to be used in a real .rc file (ultimately this is just a judgement call, though). The results of that test suite (provided in the readme) is also a better indication of how rc.exe-compatible the various resource compilers are in practice (i.e. on 'real' .rc files).
Re:Every bug/quirk of the Windows resource compiler (RC.exe), probably
on Saturday October 12, 2024 @07:54PM (#41823845)
Appreciate the added context!
> |-separated lists of numeric or NOT
Note that | is not the only operator that can be used in style parameters, & + and - are all allowed too.
> perhaps Windows versions that don't support DIALOGEX also don't support GROUPBOX
Seems possible for sure. From [1]:
> The 16-bit extended dialog template is purely historical. The only operating systems to support it were the Windows 95/98/Me series.
[1] https://devblogs.microsoft.com/oldnewthing/20040622-00/?p=38...
> The examples below this also seem to have reversed the order of the input byte and the FF.
Good catch, fixed
Re:Every bug/quirk of the Windows resource compiler (RC.exe), probably
on Saturday October 12, 2024 @07:40PM (#41823756)
Thanks!
I'm actually pretty okay with where I've landed with FONT resources. The legwork has already been done in figuring things out, and with the strategy I've chosen, resinator doesn't even need to parse .fnt files at all, so the implementation is pretty simple (I wrote a .fnt parser, but it's now unused[1]).
[1] https://github.com/squeek502/resinator/blob/master/src/fnt.z...
Re:Every bug/quirk of the Windows resource compiler (RC.exe), probably
on Saturday October 12, 2024 @05:52PM (#41823024)
I'm the author if anyone has questions
All of the listed goals have arguably been met, except:
- Auto-generating a `.h` file has temporarily regressed
- Friendly toward package maintainers is an ongoing goal
- "Memory zeroed by default" is not accurate, instead you must initialize all variables (to either some value or `undefined`)
Re:I'm forking Ladybird and stepping down as SerenityOS BDFL
on Monday June 03, 2024 @06:38AM (#40561286)
SerenityOS's browser has never been named Ladybird AFAIK, it's always been just Browser.
https://github.com/SerenityOS/serenity/tree/master/Userland/...
Ladybird was the name used for to the cross-platform version of the browser.
https://awesomekling.github.io/Ladybird-a-new-cross-platform...
Re:Arena Allocator Tips and Tricks
on Wednesday September 27, 2023 @07:59AM (#37673395)
There's support for exactly this type of OOM testing in Zig via std.testing.checkAllAllocationFailures:
- https://github.com/ziglang/zig/blob/1606717b5fed83ee64ba1a91...
- https://www.ryanliptak.com/blog/zig-intro-to-check-all-alloc...
Re:New Emojis in 2023-2024
on Saturday July 15, 2023 @03:38PM (#36740230)
How about with a maximum size of 10x10 pixels?
Re:Ask HN: Could you share your personal blog here?
on Tuesday July 04, 2023 @07:29PM (#36593800)
https://www.ryanliptak.com/blog/
A few Zig related posts, but the posts I like the most are some technical posts about the Quake/GoldSrc/Source engines:
- Rampsliding Is a Quake Engine Quirk in the Same Way That Bunnyhopping Is: https://www.ryanliptak.com/blog/rampsliding-quake-engine-qui...
- Source vs GoldSrc Movement: Downward Slopes: https://www.ryanliptak.com/blog/source-vs-goldsrc-movement-s...
Re:Quake's lightning gun bug explained
on Thursday June 15, 2023 @06:51PM (#36347866)
I wrote a breakdown of a different Quake engine quirk (rampsliding) that might be a fun topic for a video if you're looking for new topics:
https://www.ryanliptak.com/blog/rampsliding-quake-engine-qui...
Re:Zig now has built-in HTTP server and client in std
on Thursday May 18, 2023 @06:14PM (#35994893)
My understanding is that it's there to allow for testing the client. Relevant issue: https://github.com/ziglang/zig/issues/910
Re:Fuzzing Zig Code Using AFL++
on Thursday September 23, 2021 @05:20PM (#28635591)
AFL++ is not a language.