<karchnu>
How can I safely return a string from a function?
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
frmdstryr has quit [Ping timeout: 268 seconds]
<karchnu>
Wait, actually the problem seems to be that I return a structure with a string in it, but the string wasn't copied, it is just a reference to the local one in the stack.
<karchnu>
I can't do return MyStruct{.string = my_local_string };
<fengb>
Slices are reference types (pointers really)
<fengb>
To make a copy, you'll have to manually manage the memory
<karchnu>
and returning a string representation is okay only if a fixed-sized buffer is returned, with its size known at compile time, right?
<karchnu>
like fn a() [100] u8 {...}
<fengb>
Yeah, arrays are values. The compiler knows how many bytes to copy
<fengb>
(Unlike in C, where arrays degenerate into pointers...)
waleee-cl has quit [Quit: Connection closed for inactivity]
<fengb>
A hack I sometimes use is pass around a `struct { len: usize, data: [256]u8 }`
<karchnu>
I guess I will have to use heap memory since I pass values with unknown sizes inside structures that I return.
<fengb>
The data field encodes a max buffer size so it can be passed around on the stack
<karchnu>
Yes, it's a hack, and I will try not to use it. :D
<fengb>
Hey if it works and if the optimizer erases the copies, then it's better in my book :P
<karchnu>
I'm doing a parser right now, _for now_ I can just use slices over the original source. That's even better.
<semarie>
I have a C struct defined as 'struct { ... } __packed'. how to declare it in zig to keep C compat ? I assume that just 'extern struct { ...}' will not be enough, but I am unsure if 'packed struct { ... }' would have the same layout than C ABI
<semarie>
andrewrk: so using 'packed struct {...}' in zig should have the same layout than 'struct { ... } __packed' in C (with only simple types like u8, u16, u32, u64) ?
<semarie>
I think at some point I will need to have automatic tests for comparing layout between @cImport("foo.h").myStruct and @import("foo.zig").myStruct (comparing fields size, alignment, offset, ...)
HollMax has joined #zig
<HollMax>
Hi, is there a better way to do something on a missing optional that `if (foo) |_| {} else ...`?
<HollMax>
*than
<HollMax>
the documentation is talking mostly about the happy path
<HollMax>
also, I've noticed `.get()` on hashmap returns `?V`, but the docstring says it returns an optional pointer to value, which I'd expect to be of type `?*V`
KIMI_887 has quit [Remote host closed the connection]
ifreund has quit [Ping timeout: 268 seconds]
ifreund has joined #zig
<ifreund>
HollMax: if (foo == null) { ... }
<ifreund>
and yeah that doc comment looks wrong
<HollMax>
ifreund ah, thanks!
<HollMax>
Not sure if the comment is wrong, I'd say the code is wrong, as I'd rather get a pointer
<ifreund>
you could open an issue/PR to discuss
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
earnestly has joined #zig
HollMax has quit [Ping timeout: 245 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 240 seconds]
osa1 has quit [Quit: osa1]
osa1 has joined #zig
<dominikh>
ifreund: https://www.nmichaels.org/zig/interfaces.html is the article I've desperately been trying to find the other day. I wouldn't mind having that in std. (though it's not quite as zero cost because of the function pointers)
cren has joined #zig
<ifreund>
I'm not really convinced, the resulting code isn't as readable as a simple while loop and the ergonomics aren't good enough to make up for that IMO
<ifreund>
though 1717 and if accepted 6965 would help with that
<dominikh>
being able to combine data transformations can be a powerful feature
<dominikh>
can't wait for 1717 though
<dominikh>
6965 looks… interesting
proteusguy has joined #zig
<ifreund>
6965 is the closet zig might get to closures, which would be pretty big for functional-style iterator ergonomics
<dominikh>
it also stands out as a very "special" feature, in terms of Zig that doesn't work on it
proteus-guy has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
xackus has joined #zig
dddddd has quit [Ping timeout: 256 seconds]
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
osa1 has quit [Ping timeout: 246 seconds]
dddddd has joined #zig
dumenci has quit [Ping timeout: 268 seconds]
<companion_cube>
The more ergonomic you want to be, the further away from C you need to stray :p
waleee-cl has joined #zig
donniewest has joined #zig
osa1 has joined #zig
benjif has joined #zig
hf69 has joined #zig
hf69 has quit [Client Quit]
dumenci has joined #zig
hf69 has joined #zig
hf69 has quit [Client Quit]
hf69 has joined #zig
hf69 has quit [Client Quit]
fengh has joined #zig
fengh has quit [Client Quit]
fengh has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
a_chou has joined #zig
<dominikh>
do I understand right? a struct field can be 'anytype', but then the struct type can only be used at comptime?
a_chou has quit [Remote host closed the connection]
ifreund has quit [Quit: WeeChat 3.0]
ifreund has joined #zig
cole-h has joined #zig
seadragon-droid has joined #zig
Akuli has joined #zig
nvmd has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<andrewrk>
semarie, you can implement such tests with comptime blocks and @offsetOf
ifreund has quit [Ping timeout: 272 seconds]
ifreund has joined #zig
heidezomp has joined #zig
seadragon-droid has quit [Read error: Connection reset by peer]
cole-h has quit [Quit: Goodbye]
hnOsmium0001 has joined #zig
<justin_smith>
is it expected, or a known issue, that if I call get on a hash map that has 0 capacity, it blows up with an integer overflow?
<justin_smith>
it calls "const mask = self.capacity() - 1;" - I guess I need to make sure capacity is allocated or guard my get call
<g-w1>
I would submit a pr to make it return null when this happens
<justin_smith>
g-w1: that sounds like a good behavior, yeah
<heidezomp>
I'm about to submit a PR to fix compilation of getuid/getgid/geteuid/getegid on 64-bit Linux; should I add tests to ensure that these compile correctly, even though the return value cannot be tested? (so a test would basically be `_=linux.getuid()`) Or are tests like that not useful?
<justin_smith>
oh, the root cause of my bug was taking a pointer to a hash map on stack, pebkac
GreaseMonkey has joined #zig
<leeward>
Gotta love it when the debugger causes the problem you're trying to debug.
wootehfoot has joined #zig
sord937 has quit [Ping timeout: 240 seconds]
<leeward>
andrewrk: I see #4284 is targeted for 0.8.0. Do you expect to do the @volatileLoad and @volatileStore thing proposed in the original comment?
marnix has quit [Ping timeout: 256 seconds]
Akuli has quit [Quit: Leaving]
earnestly has quit [Ping timeout: 246 seconds]
earnestly has joined #zig
fengh has quit [Ping timeout: 240 seconds]
st4ll1 has quit [Ping timeout: 240 seconds]
st4ll1 has joined #zig
heidezomp has quit [Remote host closed the connection]
<andrewrk>
leeward, no action is planned yet since it doesn't have the "accepted" label
<andrewrk>
it's still an open discussion
radgeRayden has quit [Ping timeout: 272 seconds]
radgeRayden has joined #zig
donniewest has quit [Quit: WeeChat 3.0]
<leeward>
shiny
<pixelherodev>
As I understand it, targeted non-accepted issues mean "Let's try to resolve this discussion by then"
<pixelherodev>
Since we're nearing 1.0, we won't be able to afford postponing even just the *discussions* any lonter
<pixelherodev>
longer*
<rom1504>
what will make zig 1.0 ?
<andrewrk>
we're not nearing 1.0
<pixelherodev>
rom1504: "No known bugs, language is set in stone, compiler is finished"
<rom1504>
I don't know any language that is this good
<leeward>
0.9 + 0.1 is 0.10, not 1.0
<pixelherodev>
andrewrk: nearing != "we're almost there," but "we're starting to exit the stage in development where we can keep pushing stuff off to later, because we're starting torun out of laters". There's probably a better phrasing
<pixelherodev>
"Focus is largely shifting from design into implementation" maybe?
<leeward>
I suspect we'll find some important design things to change in the course of writing a compiler in Zig.
<leeward>
But you're probably right about there being more design in the past than the future.
<pixelherodev>
I think the big picture design is mostly set in stone
<pixelherodev>
(though obviously not *completely*)