#zig array to c void pointer

1 messages · Page 1 of 1 (latest)

lapis harbor
#

How do I take a zig c_uint array and pass it into a function that wants a void*.

#

I guess more specifically, how do I actually use @as because the documentation doesn't make much sense

cold halo
#

take the address of the array

lapis harbor
#

&array?

cold halo
# 
var arr = [_]c_uint{};
function(&arr);
#

yes

lapis harbor
#

No way

#

Yep that did it

cold halo
#

or if you want it explicit use @ptrCast(&array)

lapis harbor
#

Gosh I was over complicating things...

#

Thank you

cold halo
elder spear
cold halo
#

It's better when reading the code

plush trail
# cold halo It's better when reading the code

it isn't really, and it introduces a bug if the signature of function ever changes to something more strict and implicitly continues to allow you passing the array pointer without warning you, since you used @ptrCast

#

you should not use casts if you do not need to

cold halo
#

It's used in stdlib and I thought it was there for reading purpose

plush trail
#

it is used in the stdlib where it is necessary, which, for the majority of casts between pointers, it is

#

but we're talking about a coercion here, where it simply isn't

cold halo
#

It's not necessary

#

they cast from *T to *anyopaque

plush trail
#

would you mind pointing these examples you're referring to out?

#

note: there is a specific case where *T isn't allowed to coerce to *anyopaque, and it's when T = *U

#

that is to say, **U can't coerce to *anyopaque

#

if you see any @ptrCasts used for any coercion other than that, then a PR to remove those would be beneficial

elder spear
cold halo
plush trail
# elder spear why is that?

when dealing with multiple levels of pointer indirection it is a common footgun in a language like C to accidentally "cast at the wrong depth"

elder spear
#

ok makes sense i guess

plush trail
#

limiting coercion to *anyopaque to only one level of depth avoids this footgun

#

meaning 90% of cases can work easily with it, where 10% of cases have to do a little more work to express proper intent

plush trail
#

if Context = *U, then .context = &self.context would be a compile error

cold halo
elder spear
plush trail
#

not too long ago

#

maybe a week now

elder spear
#

is performance impacted in any way when everything refers to the type erased AnyReader under the hood?

plush trail
#

as per the measurements done during the PR, turns out no

#

though some benchmarks demonstrated that AnyWriter did worsen performance

#

so somethin odd happened there

elder spear
#

hmm wouldn't it be great to have a single interface Reader that could be used with compile time generics or dynamically at runtime...

plush trail
#

that is kind of what this is

elder spear
#

but its two seperate things with a ton of boilerplate because we have to diy interfaces whenever we need them

plush trail
#

yeah, "when we need them" being the key phrase

elder spear
#

imagine a world where trait Reader {...}

plush trail
#

seems like it would mostly run counter to what the change is trying to solve (that is, reducing code bloat)

elder spear
#

it would be a general interface mechanism that allows you to decide between compile time or runtime generics at the use site, like the beloved rustlang

plush trail
#

you could already do that now with this mechanism just by continuing to accept anytype

#

anyway, to #bikeshed with you

elder spear
#

yes but the definition of AnyReader + GenericReader is much more complicated with a lot of manual work that could be done automatically in a consistent fashion by zig