<pixelherodev>
There's just one mistake in that post, daurnimator
<pixelherodev>
Well... no, okay, it's technically true. Barely.
<daurnimator>
is it that their universal binaries aren't universal? or is it that their strncpy has a bug? or is it that gcc will still optimize internal calls to memcpy?
<pixelherodev>
I did "code that runs bare metal and under OS," but I used Zig, not C :P
<daurnimator>
there's several issues with it...
<daurnimator>
but there's still some useful ideas in there: e.g. optimising memcpy to have less clobbers
<pixelherodev>
Not universal, but much closer than anything else I've seen.
<shachaf>
Calling those things Linux executables is a stretch.
<pixelherodev>
So is calling them Windows binaries
<shachaf>
You can't execve them, for instance, unless I'm missing something.
<pixelherodev>
Why not?
<shachaf>
Aren't they at least real MZ/PE files?
<daurnimator>
shachaf: correct
<pixelherodev>
and ELF.
<shachaf>
Because they're shell scripts and they don't have a #! line.
<pixelherodev>
I think
<pixelherodev>
ah, never mind then?
<pixelherodev>
Thought it was doing ELF too :(
<shachaf>
You can't be MZ and ELF at the same time because the first bytes overlap.
<daurnimator>
they rely on the bash behaviour that anything without an ELF or a #! will be invoked with /bin/sh
<daurnimator>
some shells don't do that (e.g. fish)
<shachaf>
It's a shell script that starts with MZblah='...
<pixelherodev>
yeah no, that's not portable.
<daurnimator>
i.e. in the effort to be more portable; they became less portable
<pixelherodev>
I for one don't use bash
<pixelherodev>
(even on Linux, to be clear :P)
<daurnimator>
pixelherodev: what shell do you use? most do the ENOEXEC => try /bin/sh dance
<pixelherodev>
and yeah, based on commit times in that repo, I *did* beat them to the "bare metal + under-OS hybrid", but I did it at the source level and in Zig
<shachaf>
Who says you're running programs from a shell?
<pixelherodev>
Me
<pixelherodev>
Always :P
<daurnimator>
shachaf: that too :)
<pixelherodev>
But yeah, exec is another cogent point
<shachaf>
Anyway I don't want that dance, or to run a shell in order to run my program.
<shachaf>
So it's a tricksy hack but not something I'd actually use to make a program.
<daurnimator>
their universal binary shenanigans wasn't the reason I linked that blog post though
<pixelherodev>
Oh?
<daurnimator>
16:44:04 <daurnimator>but there's still some useful ideas in there: e.g. optimising memcpy to have less clobbers
<pixelherodev>
ahh
<pixelherodev>
What I found interesting about a different paper was that apparently assigning struct members is faster than memcpy()ing
<pixelherodev>
e.g. `for member in struct: new->member = old->member;` is faster than `new = old;`
<pixelherodev>
(this was in 2015, so who knows if it's still true)
<daurnimator>
I often rely on assigning struct members getting optimised to a memcpy :P
<daurnimator>
(well not so much rely on; but observed and now assume after doing profiling work)
<koakuma>
> pixelherodev: Thought it was doing ELF too
<koakuma>
It seems to be doing a self-extracting shell script/ELF combo file a la gzexe, instead of it being an actual ELF file
<pixelherodev>
So it would be able to exec() itself, but not be exec()ed, effectively
<pixelherodev>
(since it'd be an ELF while it was running, but a shell script while on disk)
<daurnimator>
could probably do binfmt_misc magic to skip the shell step for specific machines
<daurnimator>
but again... that wasn't the point of linking that article >.<
<pixelherodev>
heheh
<pixelherodev>
probably going to do a stream on zyg shortly if anyone's interested
cole-h has quit [Quit: Goodbye]
<koakuma>
Oh by the way, Zig bool is 1 when true and 0 when false, right?
<pjz>
..but I don't _wanna_ be explicit b/c I don't _care_ - I'm just trying to wrap up a library's constructor with a nice error block to reduce boilerplate
<pjz>
so instead of putting copies of `var foo = some.long.Constructor(..) catch |err| { showErrorMessageNicely(); os.exit(1); unreachable; } ; thenDoStandardCheck();` everyplace, I can wrap that up into `fn mySafeConstructor(...)`
<pjz>
sounds like maybe a job for an editor/IDE extension - 'turn this anytype into the inferred type'
jjsullivan1 has quit [Remote host closed the connection]
decentpenguin has quit [Quit: ZNC crashed or something]
jjsullivan has joined #zig
decentpenguin has joined #zig
jjsullivan has quit [Quit: leaving]
jjsullivan has joined #zig
jjsullivan has quit [Client Quit]
jjsullivan has joined #zig
eddyb[legacy] has quit [Ping timeout: 246 seconds]
ovf has quit [Ping timeout: 246 seconds]
jzelinskie has quit [Ping timeout: 258 seconds]
eddyb[legacy] has joined #zig
jzelinskie has joined #zig
ovf has joined #zig
a_chou has quit [Remote host closed the connection]
jjsullivan has quit [Quit: leaving]
jjsullivan has joined #zig
<pixelherodev>
Streaming zyg work in ~3 minutes if anyone's interested :)
ur5us has joined #zig
xackus has joined #zig
leon-p has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
nycex- has quit [Ping timeout: 240 seconds]
nycex has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
lucid_0x80 has joined #zig
koakuma has quit [Quit: Leaving.]
wootehfoot has joined #zig
wootehfoot has quit [Remote host closed the connection]
riba has joined #zig
koakuma has joined #zig
lucid_0x80 has quit [Ping timeout: 246 seconds]
dumenci has joined #zig
plakband has joined #zig
xackus has quit [Ping timeout: 272 seconds]
donniewest has joined #zig
plakband has quit [Quit: WeeChat 2.9]
xackus has joined #zig
plakband has joined #zig
radgeRayden has joined #zig
cren has joined #zig
gpanders has quit [Ping timeout: 240 seconds]
gpanders has joined #zig
plakband has quit [Quit: WeeChat 2.9]
<oats>
in "arr[f(foo)] = f(bar);" does f(bar) get evaluated before f(foo)?
<oats>
or afterwards
<pixelherodev>
I don't thinkthat's defined
<pixelherodev>
oats: my personal rule for constructs like that is "split it into two lines"
<pixelherodev>
If you were wondering this now, someone else reading it (or you a month from now!) will have the same question
<oats>
excellent point
<pixelherodev>
Readability is important!
<pixelherodev>
:)
<semarie>
how test-translate-c are done ? I have a test error which look like a double-free
<semarie>
minimized, it is: expected `break :blk ref.*;' found `break :@"\xdf\xdf\xdf" ref.*;'
<semarie>
and the 0xdf bytes in the string are usually openbsd libc signature for free-ed data.
<semarie>
so it more likely a use-after-free
nycex has quit [Ping timeout: 240 seconds]
waleee-cl has joined #zig
koakuma has quit [Quit: Leaving.]
swills has quit [Quit: swills]
<g-w1>
I am getting a super weird linking error when using c code and zig code in the same project (EmoteCache.o is from EmoteCache.c) https://paste.rs/yy2 apparently lld cant parse the .o file? here is the .o file https://paste.rs/Kxh
nvmd has joined #zig
swills has joined #zig
<semarie>
g-w1: the .o seems corrupted in some way: readelf -a Kxh => readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
<g-w1>
thats so weird, I tried to clear the cache multiple times, and it still doesn't work
<justin_smith>
what's the right way to allocate a 2d array when the dimensions are determined at runtime? I've been using an array of pointers then putting an array under each pointer but that's annoying to work with
<justin_smith>
(since alloc allows a runtime arg for size, but I can't figure out how to do that with 2 dimensioms)
TheLemonMan has joined #zig
<TheLemonMan>
g-w1, no wonder LLD doesn't like your .o file, that's a precompiled C header
<TheLemonMan>
the first four byte give it away, CPCH
<justin_smith>
n/m, I can of course allocate an array under each index without having to statically specify its dim
<g-w1>
oh, i mustve messed up something in my build.zig
<g-w1>
now it works! thanks. I did exe.addCSourceFile("EmoteCache.h") instead of EmoteCache.c
<TheLemonMan>
I love the smell of solved problems
cole-h has joined #zig
cole-h has quit [Client Quit]
<andrewrk>
sup TheLemonMan did you see that FireFox317 contributed the initial LLVM backend for stage2?
<andrewrk>
it's not landed yet
cole-h has joined #zig
<TheLemonMan>
nope, holiday season means little to no spare time for me, I didn't even answer your mail yet (did I?)
<andrewrk>
nope I don't think you did
<andrewrk>
hope you've been enjoying the holidays
<TheLemonMan>
yeah, gotta close this awful year on a positive note
<TheLemonMan>
oh, the deadlock problem was trickier than expected
<andrewrk>
yeah did you see the final resolution?
a_chou has joined #zig
<TheLemonMan>
yeah, doing as much work as possible before fork() is a good strategy
a_chou has quit [Client Quit]
<TheLemonMan>
I wonder why it's never been a problem for all this time
<andrewrk>
because I'm not the first person to make this mistake, and so glibc (and newer musl versions) make it work even though it's UB
<andrewrk>
apparently aarch64 alpine linux (which we use on drone ci) is stuck on musl v1.1.24
<TheLemonMan>
the perks of using old software, take that Arch!
<leeward>
There's a reason they call it the bleeding edge.
<leeward>
Oh, hey, is there (or maybe will there ever be) a way to tell Zig to put a symbol at a particular address? Standard libraries for embedded processors are frequently full of SFR definitions, and it would be nice to write Zig code as `mcu.P1SEL = 0xC0` instead of `mcu.P1SEL.* = 0xC0`.
<leeward>
It's not a gigantic deal, but it would save about 2-3% of the characters in my current project.
<leeward>
and shorten about 35% of the lines
xackus has quit [Ping timeout: 272 seconds]
jjsullivan has quit [Remote host closed the connection]
<g-w1>
andrewrk: about your comment on #7191, what exactly is leaking if ErrorMsg.create fails? and do you mean every instance of addDeclError introduces a leak, or only those three in Compilation.zig?
<andrewrk>
g-w1, if the 1st try succeeds, but then the 2nd one fails, the memory is leaked
<andrewrk>
that's why the code had ensureCapacity before
nycex has joined #zig
<g-w1>
ah, I see. an errdefer destroying the message will fix it. thanks for the feedback
<andrewrk>
np. I reverted the commit for now since it had that other issue I wanted to push back on too
jjsullivan has joined #zig
<g-w1>
ok, so I wont submit a pr to fix it
<andrewrk>
this would be a good time to point out I do appreciate all the contributions you've been making
<TheLemonMan>
andrewrk, what's your stance on #7477 ?
<andrewrk>
where's the footgun in that last comment there?
<pjz>
any chance on reconsidering #447 at least wrt non-pub functions ?
<TheLemonMan>
the missing `extern`
<TheLemonMan>
that's even worse when you're dealing with C APIs using *c_void
<andrewrk>
I see, because the layout won't match the C version
raggi has joined #zig
<TheLemonMan>
yeah, that's a source of hard-to-debug problems
dumenci has quit [Ping timeout: 260 seconds]
<andrewrk>
TheLemonMan, my stance is that ABI boundaries are unavoidable footguns. A single typo can result in this kind of bug. Also `packed` vs `extern` or a missing `align`. So I don't find this argument compelling. I think pointers to things should be OK in the C ABI boundary
<TheLemonMan>
it's a pointer to something you can't use from the C side
gpanders_ has joined #zig
<TheLemonMan>
that's something you'd use @opaque for, and I think that's also what -femit-h does
gpanders has quit [Ping timeout: 265 seconds]
<andrewrk>
you use opaque for when the C code has the definition; you just use a pointer when your own code has the definition and the C side doesn't
<andrewrk>
doesn't your patch introduce pointer casts that previously weren't there?
<andrewrk>
yep there it is
<andrewrk>
no good; this introduces a footgun while promising to take one away
<TheLemonMan>
the casts are done on the Zig side because we're crossing the boundary twice
<andrewrk>
the zig code has no boundary to cross
<fengb>
It’d just be a forward declared struct in C
<fengb>
And we could avoid defining an extra export function just for C
<TheLemonMan>
the front-end is written in Zig, the backend is written in C++ and calls into the Zig code
<TheLemonMan>
so the Progress objects go Zig -> C++ -> Zig, that's why you need the ptrcast
<andrewrk>
the zig code is all one object; the Progress struct in both cases is part of the same compilation
<TheLemonMan>
yes? I'm not following anymore
<TheLemonMan>
I think @opaque is the solution whenever you don't want/you can't leak the definition to the C side, like we do for the Progress structure
<TheLemonMan>
like a *c_void, but type-safe
<andrewrk>
it's the other way around, opaque is the solution when you can't leak the definition to the Zig side
<andrewrk>
the type is opaque *to zig*
<andrewrk>
opaque is the wrong type for std.Progress
<ifreund>
I've had crashes because I forgot an extern before while writing wlroots bindings and this check would have prevented that code from compiling
<andrewrk>
I recognize that as one of many footguns at the ABI layer. I don't think it stands out as any more precarious than any other one, and it introduces footguns to take this feature away (see the new pointer casts in #7477)
<ifreund>
I think requiring an explicit @ptrCast() on the ABI boundry when passing a non-extern struct is a good tradeoff
<TheLemonMan>
well, the opaqueness is valid on both sides of the ABI boundary, why not take advantage of the "other half" ?
<ifreund>
I may be missing something but I just see more verbosity not new footguns
<andrewrk>
ifreund, I disagree. That same logic could be used to argue that extern function declarations should have no types at all, and you should have to pointer cast to get any type out of an external symbol. At which point we've reinvented extern fn declarations
<andrewrk>
the fact is that an ABI declaration must be correct and there is no type safety available to check your work. a pointer to a zig struct is a valid type of parameter in a C ABI function
<TheLemonMan>
how is that specific @ptrCast a footgun? every single @ptrCast is a footgun if you're not careful enough
<TheLemonMan>
and I'd expect people to know what they're doing when playing with this kind of non-trivial C/Zig interop
<andrewrk>
that's my point. if we treat all footguns as equal you've removed one and you've added one, so net zero, while making the code more complex
<TheLemonMan>
I wouldn't say it's more complex, there are only 3-4 @ptrCast in the whole codebase (compiler+runtime+stdlib) that are going away once the stage1 gets the boot
<TheLemonMan>
and, as I wrote on the ticket, this is the only irregular case where the child type isn't checked
<TheLemonMan>
if you declare the parameter as a C array (that eventually decays into a pointer anyway) you get a cold hard compile error
<andrewrk>
I don't understand that argument - it's also the only case where it's a pointer, so the meaning of a child type is different
<ifreund>
That's a good point, one of these foot guns is much more common in practice
<andrewrk>
what do you mean to declare the parameter as a C array? zig doesn't have "C array" types
<andrewrk>
zig arrays have no corresponding C type, hence compile error
cole-h has quit [Quit: Goodbye]
<andrewrk>
as a reminder we also have https://github.com/ziglang/zig/issues/168 which includes a partial shuffling of fields for debug builds to catch issues such as this
<ifreund>
I think TheLemonMan was saying that you aren't currently allowed to pass an array of non C ABI types over they ABI boundry without a pointer cast
<andrewrk>
right because there is no C type corresponding to that. But if it were a pointer to such a thing, there would be a C type for that - a forward declared struct
cole-h has joined #zig
<TheLemonMan>
in iter_function_params_c_abi arrays are passed as pointers and type_allowed_in_extern does allow arrays
<TheLemonMan>
from the C POV there's no difference between the two, so why the difference?
<andrewrk>
this is correct, if you find an example where it allows arrays, that's an implementation bug
<TheLemonMan>
alright, I stand corrected
<andrewrk>
I'm pretty confident in this design decision
<TheLemonMan>
but it still feels like a weird special case, arrays not being allowed aside
<ifreund>
I don't hate the status quo tbh. Eventually someone will probably write a static analysis tool to give me warnings for this
<TheLemonMan>
if we take river as an example, this change would introduce zero @ptrCast, right?
<andrewrk>
in zig code we model external things strictly from zig's perspective
<ifreund>
TheLemonMan: I disagree that it feels like a special case. The pointer itself has a well defined representation on the ABI boundry, so it's allowed.
<ifreund>
It feels different from how C headers work for sure though
<andrewrk>
the other side of C ABI might not even be C. It could be any other language, even zig
<TheLemonMan>
a pointer to... something you can't declare! isn't that an opaque type?
<ifreund>
it would be in a C header declaring this function
<andrewrk>
but we can declare it. the definition is right over there: struct Foo { a: T, b: T}
<TheLemonMan>
yeah, if you twist the meaning of opaque to mean "opaque for Zig" then it makes sense
<TheLemonMan>
I meant on the C side
<ifreund>
that's how I interpert opaque currently at least
<ifreund>
extern definitons aren't an API spec though
<ifreund>
if you want someone to use your library you'd write a C header and use an opaque struct
<andrewrk>
right. and with a zig-emitted .h file it would emit a forward declared struct
<TheLemonMan>
my interpretation is a bit wider, I'm using that for types I want to keep on one or the other side
<ifreund>
TheLemonMan: you're right though, if we look only at river and it's dependencies/bindings this change would be a strict improvement to safety
<ifreund>
river is not a good example though for this use case
<TheLemonMan>
I'll make my own fork of Zig with blackjack and hookers and @opaque types
<ifreund>
I expect this to come up a lot more when writing Zig libraries exporting a C ABI
<companion_cube>
you could call it zen++
<companion_cube>
or zune
<TheLemonMan>
well river is heavy on handcrafted C bindings
<TheLemonMan>
zen++, I like how that sounds
<companion_cube>
river.zenpp
midgard_ has joined #zig
<ifreund>
TheLemonMan: indeed, but you won't find a single export statement
<andrewrk>
hmmmm. in theory I think we could make it a compile error if the type is never exported
<TheLemonMan>
I think the biggest library written in Zig is the compiler_rt, that's full of @export
<andrewrk>
it's only because we export the type that it could ever be passed in an extern fn
<andrewrk>
the difference between export / extern is a nice observation
midgard has quit [Ping timeout: 256 seconds]
<ifreund>
TheLemonMan: if I were to implement e.g. libwayland's API in zig I would want to use non-extern structs behind all the opaque pointers for example
notzmv has quit [Ping timeout: 260 seconds]
<ifreund>
alright andrewrk's convinced me that the status quo is better
<TheLemonMan>
under the "opaque for zig" light that makes sense
<TheLemonMan>
I'm still not sold tho, next time you get a nasty crash because of a missing extern please think of me :>
<andrewrk>
ok, deal
<ifreund>
TheLemonMan: I still want a static analysis tool to spit warnings at me :D
<ifreund>
but that can come way down the road
<ifreund>
hmm, should probably paste this chat log as a comment on the PR...
<ifreund>
done
<TheLemonMan>
I tried to paste a link to the irclog but got a 502, damn it
FireFox317 has joined #zig
<FireFox317>
andrewrk, regarding #7498 (llvm backend) do you mind if I just push more commits to the PR (to implement more functionallity)? Or would it be better to keep this one small?
ur5us has joined #zig
<andrewrk>
FireFox317, if you don't mind rebasing it and fixing the conflicts, I'll make an effort to merge that today
<andrewrk>
I think if we got the first version landed before you added commits to it, it would help prevent more conflicts while you work
<FireFox317>
andrewrk, ah yeah let me rebase that. Don't think there will be any conflicts tho
<andrewrk>
I'm hoping to merge a big chunk of everyone's stage2 PRs today
<FireFox317>
ah nice! Branch has been rebased btw. I did have some conflicts which are solved now :)
<andrewrk>
thanks!
<andrewrk>
yeah let me try to focus on getting this landed before you add commits to it if you don't mind
<FireFox317>
andrewrk, no problem, thats fine! However currently the genArg function does nothing (which is pretty bad), because i dont store ValueRef's yet
<FireFox317>
I will address that in further PR's for sure
<FireFox317>
Have to reboot (dual-boot), but will check the logs if someone mentiones me :P
FireFox317 has quit [Quit: Leaving]
<andrewrk>
FireFox317, I'll have a look, thanks! As a general rule, try to emit a compile error for TODOs rather than miscompile or crash
hnOsmium0001 has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
riba has quit [Ping timeout: 264 seconds]
<leeward>
and shorten about 35% of the lines
<leeward>
whoopsie
<leeward>
heh, hitting up arrow then enter in the wrong window produces funny results sometimes
FireFox317 has joined #zig
<FireFox317>
andrewrk, yup. I tried to do that as much as possible
l1x has joined #zig
<pjz>
is there a way to get the return type of a runtime function? @TypeOf won't work on them, correct?
<ifreund>
introspection in generaly only works at compile time
<ifreund>
what are you trying to acheive?
cren has quit [Quit: cren]
<pjz>
oh, I'm trying to wrap up a call that's way too complicated. I ran into a TODO for #447 so I just gave up and did copypasta for now
<pjz>
I'm trying to refactor some boilerplate error handling: https://github.com/pjz/zkg/blob/parse_better/src/main.zig#L57 but it's telling me "unable to evaluate constant expression" and pointing at the first arg... which isn't even comptime.
<ifreund>
the std.mem.Allocator interface doesn't work at comptime
rzezeski has quit [Quit: Connection closed for inactivity]
<dch>
e.g. `{"master": {"version": "0.7.1+f75d4cbe5",sha:"f75d4cbe5" ...` for example
<andrewrk>
ok
<dch>
I can hack it out of version directly, obviously. but I can feed the sha into a wee script here and have a lang/zig-devel port available every few days for freebsd
<dch>
hopefully people will get distracted by regular updates and come over to see what all the fuss is about
<dch>
tyvm
<andrewrk>
np
<FireFox317>
andrewrk, do you think it is a good idea to use the current branch_stack abstraction (in codegen.zig) in the new llvm backend too?
<andrewrk>
that abstraction is W.I.P. if I remember correctly
<andrewrk>
it's intended to be used for register allocation, so I don't think it applies to LLVM IR generation, because LLVM does its own register allocation
<ikskuh>
andrewrk: can you explain 7582? :D
<andrewrk>
ikskuh, yeah it's real simple, make this code work in stage2
<ikskuh>
is it "implement that in stage2" or? :D
<FireFox317>
andrewrk, okay i see, thanks :)
<ikskuh>
andrewrk: you should note that in a sentence probably. it's confusing :D
<andrewrk>
label:stage2 label:enhancement
<andrewrk>
I need a github url to past into a comment