<cameris>
But isn't it not kind of dangerous to implicitly cast arrays to slices (basically pointers), at least for return values?
<hryx>
it can be -- the buggo I asked about earlier is (I think) caused because of returning a slice into a stack allocated array -- one whose pointer is no longer valid after returning
<hryx>
but returning a slice into a heap-allocated array is fine
<hryx>
in fact cameris that's the interface of an allocator in zig
<hryx>
it returns e.g. []u8
<Tetralux>
A slice is essentially an array that doesn't own it's memory - it points to someone else's.
<Tetralux>
If that memory is on the heap, then you can return it.
<Tetralux>
If it's on the stack, you can return it... but it will get clobbered by other local variables the next time you call a fn.
<Tetralux>
And so you should not do that.
<Tetralux>
.. Which is what happens when you do { var x: [4]u8; return x[0..]; }
<cameris>
yeah, ofc you can return a slice. But what I find disturbing is that you could return an array inside such a function and it is implicitly cast to a pointer(==slice).
<Tetralux>
It isn't.
<Tetralux>
It's "casted" by x[0..]
<Tetralux>
The slicing syntax is what's casting it.
<Tetralux>
Although "casting" is not the right word here.
<Tetralux>
But you get my point.
<Tetralux>
Unless I'm not understanding what you mean :p
<cameris>
ok. But #2749 wants exatly that.
<hryx>
I see your point cameris, but to echo Tetralux, the implicit cast only happens because the return type of the function demands it
<hryx>
implicit cast from array to slice is very useful. but I do see how this might be a gotcha
marijnfs_ has joined #zig
<cameris>
and boolToStr does `return "true"` instead of `return "true"[0..]`, but for strin literals that seems fine I guess.
<Tetralux>
I don't really understand where this whole "implicit" thing is coming from - because it isn't. The [0..] is explict.
<hryx>
cameris: regarding 2749, I probably should have used a different type to demonstrate the issue, which is about peer resolution and not array-to-slice specifically
<Tetralux>
And yes.
<mikdusan3>
i hope i'm correct here; when creating the expression for array... if it's LITERAL then safe to slice and return. if there is any runtime item in array, it's no longer literal and now stack-based and unsafe to slice/return.
<Tetralux>
If the type is [N]T
<Tetralux>
Then it's on the stack.
<Tetralux>
And you should not return a slice that into to it.
<hryx>
Tetralux: `[_]u8{c}` is an array type. so in my example in 2749, it is implicitly being cast to a slice `[]u8{c}`
<hryx>
upon being returned
<mikdusan3>
i'm looking at llvm-ir and if [N]T is something like [_]u8{ 1,2,3 } is not stack.
<mikdusan3>
var a: u8 = 10; [_]u8{ 1, a, a } is stack tmp. so that would be unsafe to slice/return.
marijnfs__ has quit [Ping timeout: 248 seconds]
<Tetralux>
See - there's a point there that I agree with. Having the _ tells me "infer how many goes here". So if it produces an array that isn't on the stack, I'd consider that a bit of a gotcha.
<Tetralux>
Unless there's some reason for that that makes more sense.
<mikdusan3>
i wonder if this is something the compiler could check. if stack sliced is returned, emit error.
<Tetralux>
I think there are considerations of that.
<Tetralux>
I don't know if there's an issue for it, but I seem to recall the idea that it would become a compile error.
fengb has joined #zig
<emekankurumeh[m]>
there's an open issue for it
<fengb>
Returning a pointer to a stack variable generates an error so the same should apply for slices
<Tetralux>
^
<cameris>
well, thx everyone for clearing that up for me.
ajhager has quit [Ping timeout: 260 seconds]
<Tetralux>
cameris, Welcome o7
<hryx>
mikdusan3: pushed your change, thanks so much
<mikdusan3>
👍
<hryx>
I'll make it not return a bad pointer too, even though tests are passing for me locally
marijnfs_ has quit [Ping timeout: 252 seconds]
marijnfs_ has joined #zig
<tgschultz>
not necessarily. comptime [N]T is totally a thing.
<tgschultz>
ack, I was a few lines behind it seems
<Tetralux>
hyrx: If you return it and then immediately read it without calling anything else beforehand, it's very possible it'd work.
marijnfs__ has joined #zig
<hryx>
Tetralux: surely that explains why the tests passed sometimes. but since the behavior is undefined I shouldn't leave it in there
marijnfs has quit [Ping timeout: 245 seconds]
cameris has quit [Quit: Lost terminal]
wootehfoot has quit [Read error: Connection reset by peer]
<Tetralux>
Seems reasonable.
marijnfs_ has quit [Quit: WeeChat 2.4]
curtisf has joined #zig
Hejsil has quit [Remote host closed the connection]
hoppetosse has quit [Quit: Quit]
<mikdusan3>
is this activated only for non-NDEBUG builds, for performance reasons?
laaron- has quit [Remote host closed the connection]
laaron has joined #zig
ajhager has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<fengb>
incompatible types: 'u16' and 'i8'
<fengb>
Shouldn't I be able to do 'u16' + 'i8'?
<curtisf>
what would you expect the result type to be in that case? i16?
<fengb>
u16
<tgschultz>
fengb: consider the case that u16 = 1 and i8 = -2. The result would overflow. That's fine, but zig requires you to be explicit about how you want that to go down.
<fengb>
Subtract if it's negative
<curtisf>
why u16? is it because it has more precision? or because that's the left operand type?
<fengb>
Both in this case :P
<curtisf>
it seems weird that u16 + i16 would be u16 but i16 + u16 would be i16
<curtisf>
I really think that this kind of thing should require an explicit cast
<fengb>
tgschultz: but overflow can happen already. And I don't have an operator for 2s complement overflow for mixed types
<tgschultz>
while that behavior may be obvious for your particular use case, I can think of several other behaviors that would be obvious for others, which is why zig requires the explicitness.
<fengb>
I kinda want another operator here :P
<tgschultz>
anyways, why not just bitcast it to u8?
<tgschultz>
my_u16 +%= @bitCast(u8, my_i8)
<fengb>
Because I need subtraction and the bigger addr
<tgschultz>
adding a bitcasted i8 is the same as what you're doing because that's how two's compliment works.
<tgschultz>
well, until you go negative on the result anyway
<curtisf>
maybe specifically `+%` could allow unsigned +% signed?
<fengb>
u8 negative isn't u16 negative
<fengb>
I'd have to extend the i8 negative into u16 negative space
<tgschultz>
oh right, there is that. you'd have to sign extend it to i16, forgive me
<curtisf>
will bitcast not sign extend for you?
<tgschultz>
you can only bitcast to something that has the same byte representation
<fengb>
I could intCast to i16 then bitcast to u16
<tgschultz>
so you can bitcast i8/u8, i4/u8, i13/u16, but not i8/u16
<fengb>
I'll toss this into a function and deal with it later
<fengb>
As much as I'm complaining... this is helping find some brutal edge cases that were totally hidden in my C code
<tgschultz>
there's a reason zig makes you be explicit
<curtisf>
Maybe `@bitCastSignExtend` would be useful? Although I suppose it can be implemented in terms of bit-casting and int-casting so maybe it could just be a library function if it's not already one
<fengb>
I didn't know about bitcast though. That's really handy thanks
_whitelogger has joined #zig
ajhager has quit [Ping timeout: 260 seconds]
<daurnimator>
curtisf: the whole point of @bitCast is it has to be the same exact size
<daurnimator>
its casting bits
<daurnimator>
fengb: I think you're looking for: @bitCast(u16, @intCast(i16, myuint8)) or you can probably write: @bitCast(u16, i16(myuint8))
<curtisf>
but sign extending does involve the same bit pattern; I don't think it's unreasonable to tie them together since it really is a single operation since part of the 'interpretation' of a type from bits includes how to fill in "missing" leading bits. I see it a bit unfortunate that you need to write both `u16` and `i16` in that expression when it does
<curtisf>
n't actually add anything to clarity or safety (in fact it's a place where a typo / miscommunication becomes possible)
<daurnimator>
curtisf: but you can't bitcast e.g. a u8 to a u16. you can't bitcast to something a different size
<curtisf>
why not, though? For example, the bit pattern `0b1111` interpreted as an `i8` *is* -128, because this is how twos-complement numbers are interpreted
<curtisf>
I think it's reasonable for this to maybe be a concept with a slightly different name, but I think this is a reasonable concept to include in the language or at least in the standard library
darithorn has quit [Quit: Leaving]
<fengb>
It's not quite as nice since underflows and overflows should be treated distinctly
<fengb>
But... in my case I don't care so it works :P
<fengb>
Casting to unsigned makes all subtraction operations overflows, which isn't always correct
<fengb>
Er... not subtraction but rather "add by negative" triggers overflow, but so does actual overflow (0xFFFFFFFF + 1 vs 1 + 0xFFFFFFFF)
<fengb>
It's late and my words are failing
<daurnimator>
curtisf: 0b1111 is a comptime_int
<daurnimator>
curtisf: you can't bitcast a comptime_int
<curtisf>
I was referring abstractly to the concept of 4 bits, not a zig literal
brakmic has joined #zig
hio has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
curtisf has quit [Ping timeout: 260 seconds]
laaron- has joined #zig
laaron has quit [Remote host closed the connection]
fubd has joined #zig
ajhager has joined #zig
<fubd>
trying to build the https://github.com/andrewrk/tetris tetris example this morning on windows, but i'm having trouble with the linker, and getting more info out of its errors...
<fubd>
but when i open the DLL that corresponds to the glfw.lib i'm linking against, i see the glfwSetErrorCallback function
brakmic has quit [Ping timeout: 245 seconds]
brakmic_ has joined #zig
<fubd>
now I've got to this ponint:
<fubd>
C:\Users\Kevin\src\tetris>zig build play -Dwindows=true
brakmic has joined #zig
<fubd>
is windows/msvc supported yet?
ajhager has quit [Ping timeout: 260 seconds]
brakmic_ has quit [Ping timeout: 248 seconds]
<fubd>
C:\Users\Kevin\src\tetris>zig --libc win.libc build play -Dwindows=true
<fubd>
C:\Users\Kevin\src\tetris>zig build play --libc win.libc -Dwindows=true
<fubd>
It's not clear to me where I should be putting the --libc argument.
avoidr has joined #zig
ajhager has joined #zig
ajhager has quit [Ping timeout: 260 seconds]
Ichorio has joined #zig
fubd has quit [Ping timeout: 260 seconds]
wootehfoot has joined #zig
Flaminator has joined #zig
Hejsil has joined #zig
avoidr has quit [Quit: leaving]
IntoxicatedHippo has joined #zig
<IntoxicatedHippo>
Is there some way I could do this? comptime { asm (@embedFile("foo.s"); }
<IntoxicatedHippo>
Nevermind, I've just realised the compiler has a flag to add assembly files
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 252 seconds]
steshaw has quit [Quit: Connection closed for inactivity]
lunamn has quit [Ping timeout: 272 seconds]
avoidr has joined #zig
fubd has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
brakmic_ has joined #zig
fubd has quit [Ping timeout: 260 seconds]
brakmic has quit [Ping timeout: 258 seconds]
Hejsil has quit [Remote host closed the connection]
brakmic has joined #zig
lunamn has joined #zig
brakmic_ has quit [Ping timeout: 245 seconds]
IntoxicatedHippo has quit [Quit: Leaving]
lunamn has quit [Ping timeout: 258 seconds]
lunamn has joined #zig
ajhager has joined #zig
lunamn has quit [Ping timeout: 246 seconds]
darithorn has joined #zig
ajhager has quit [Ping timeout: 260 seconds]
vexu has joined #zig
<scientes>
how do i resolve a ZigTypeIdMetaType to a real type?
<scientes>
i probably shouldn't be using it at all, but i realized get_vector_type returns a metatype rather than a type
<scientes>
oh it looks like i can just pun it to a vector
<scientes>
nvm
Akuli has joined #zig
vexu has quit [Ping timeout: 246 seconds]
darithorn has quit [Quit: Leaving]
lunamn has joined #zig
knebulae has quit [Ping timeout: 272 seconds]
fubd has joined #zig
knebulae has joined #zig
darithorn has joined #zig
vexu has joined #zig
vexu has left #zig [#zig]
vexu has joined #zig
Flaminator has quit [Disconnected by services]
Flaminator has joined #zig
<fubd>
I'm trying to call a function in a DLL/lib with @cImport on Windows, but the linker isn't prefixing my function name with an underscore. using `dumpbin /exports glfw.lib` shows that the exported functions look like _glfwInit
<fubd>
how do I get lld to prefix my function names?
<darithorn>
fubd are you trying to use glfw in zig?
<darithorn>
inside your @cImport you can just do @cInclude("GLFW/glfw3.h"); and then in your build.zig you link the DLL there
<darithorn>
but i may be understanding your issue incorrectly
fubd has quit [Ping timeout: 260 seconds]
darithorn has quit [Quit: Leaving]
vexu has quit [Ping timeout: 248 seconds]
Ichorio_ has quit [Ping timeout: 264 seconds]
rbscott has joined #zig
<rbscott>
Hello, I am stuck trying to figure out how to use the function sqlite3_bind_text from zig, the last argument is a callback and can pass sqlite3.SQLITE_STATIC = 0, and is compile time error. sqlite3.TRANSIENT is -1, and that is also a compile time error. Probably an easy fix, but I am at a loss.
samtebbs has joined #zig
st4ll1 has quit [Ping timeout: 245 seconds]
fubd has joined #zig
<fubd>
@darithorn i am doing that
<fubd>
but the issue is that my glfw is built by a windows linker
<fubd>
which prefixes all function names with an underscore
<fubd>
but when i cImport the header, zig is expecting to link with the functions without underscores
<samtebbs>
andrewrk: When trying to copy what you did with build_options in clashos, I get an `error: FileNotFound`. I'm adding the build_option with `const obj = b.addObject(file, file_path); obj.addBuildOption(u8, "test", 'a');`
<HelloThere54321>
I need some help with a generic list, I need a list that can have any type of data
<emekankurumeh[m]>
a homogeneous or heterogeneous list?
vexu has joined #zig
<Tetralux>
I am also curious about how one might do that.
<curtisf>
(assuming you mean heterogenous list) what do you need to do with it? do you operate on it at comptime or at runtime?
<HelloThere54321>
both i guess
<HelloThere54321>
at runtime
<HelloThere54321>
but will know the types and values at comptime
<curtisf>
to clarify: you need heterogeneous lists? std.ArrayList does not do what you want?
<curtisf>
For heterogeneous lists, I think you could use an array of TypeInfo, and an array of pointers-as-integers. Your `get` function would take a position, and (comptime) the type expected to be at that position, and it would assert that the TypeInfo matches, and then do the pointer cast for you.
<Tetralux>
You might also be able to store an array of struct { info: TypeInfo, valuePtr: usize } and do the same thing as above.
moo has quit [Quit: Leaving]
wootehfoot has joined #zig
<curtisf>
locality would be better for storing them separately, no? but yea a list of pairs instead of a pair of lists would also work
darithorn has joined #zig
<curtisf>
(especially if you want to turn of type-verification in release builds)
<HelloThere54321>
but the types of each tuple will be different and so cant declare a variable with a type as you dont know the type yet
<Tetralux>
You'd store std.ArrayList(Any), where const Any = struct { info: TypeInfo, valuePtr: *void };
<Tetralux>
The struct is the same type regardless of what type is stored within.
<HelloThere54321>
are, so u can have a void pointer
<Tetralux>
I would hope so.
<emekankurumeh[m]>
no you would have to have something like a *@OpaqueType
<Tetralux>
That's kind of weird that you cannot say *void...
<Tetralux>
But no matter
<Tetralux>
Just store it as a usize instead then.
<Tetralux>
And put a comment that it's a pointer, unless valuePtr is clear enough.
<HelloThere54321>
coolio, i'll try the *@OpaqueType
<HelloThere54321>
then will have to case
<HelloThere54321>
or take the address and store in usize :)
<Akuli>
i think someone has zig "void pointer" code on github
<Akuli>
last time i asked the suggestion was to make a big union(enum) :D
<curtisf>
well... if you actually can list out all of the possible cases that's probably going to be more understandable
samtebbs has quit [Ping timeout: 248 seconds]
<curtisf>
Oh, can you not use method syntax with comptime args? Do comptime args have to appear first? That's kind of inconvenient
Hejsil has joined #zig
<HelloThere54321>
cant seen to find the github thing, could u find a link
<emekankurumeh[m]>
zig's lazy analysis is kinda making me mad right now
<emekankurumeh[m]>
i spent way too long trying to figure out why some symbols weren't being exported until i realized it was because i didn't have `comptime { _ = already_imported_module; }` in my files
<Tetralux>
Things that are exported should probably always be there?
<Tetralux>
Also tgschultz, that's interesting. Kinda hard to follow, but interesting that you can do that.
<emekankurumeh[m]>
nope, because the file imported wasn't used anywhere so zig didn't compile it
<Tetralux>
But `already_imported_module` though?
<Tetralux>
Oh oh
<tgschultz>
Yeah, sorry, the blog entry was meant to try and explain the base concept, but I admit it isn't my best documentation.
<Tetralux>
It wasn't compiling it because without the comptime block using it
<Tetralux>
It just goes "Meh - don't need this!"
<Tetralux>
Whereas with it, it's forced to look at it, and therefore includes it?
<emekankurumeh[m]>
which is strange because i wasn't getting any errors despite the linker file needing those symbols
<Tetralux>
tgschultz, I gotta be honest, I find the code to actually make that work pretty unreadable and hard to understand xD
<Tetralux>
emekankurumeh[m], That... is quite odd.
<tgschultz>
Well the base version is pretty simple, but the version I distribute does some code reuse, so yeah. The basic idea is that you have a struct type S, right? That contains a member representing the type you want to store, T, as well as some other struct P. Then you create another struct S' where P is S, then do it again, and again... then there are some accessor functions to allow accessing the desired embedded value by some
<tgschultz>
identity. In Tuple, it's an int.
<Tetralux>
I see.
avoidr has quit [Quit: leaving]
<Tetralux>
I feel like varargs would be useful here...
<tgschultz>
you'd think that wouldn't you? unfortunately not, due to not being usable in comptime functions
<tgschultz>
that'll be remedied when varargs are replaced
<Tetralux>
Something like "const T = MakeStruct(U, V, W, X, Y, Z).init(1, f64(2.0), f32(3.0), u64(47));
<Tetralux>
And not only that
<Tetralux>
But have it easier to write such an implementation without having to resort to things like PsudeoStruct and .Add and Self.Add and things.
avoidr has joined #zig
<Tetralux>
I'd have to read it like 5 times to figure out how it actually did what it's doing xD
Hejsil has quit [Remote host closed the connection]
<tgschultz>
actually you could just do `const T = Tuple(u8(1), f65(2.0), f32(3.0), u64(47));` if varargs worked right at comptime
<tgschultz>
there's a variation of that already in Psudo
<Sahnvour>
I look forward to when we won't have to go to such lengths to create types :) but it's impressive nonetheless tgschultz
steshaw has quit [Quit: Connection closed for inactivity]
<scientes>
how do i test if something is undefined?
<Sahnvour>
scientes: you can't really, unless you have a reserved value to represent a particular undefined state
<scientes>
cause i need it to write a test
<scientes>
oh actually i can
<scientes>
because it is just a bool
<scientes>
and undef with be != true, and != false
samtebbs has joined #zig
<scientes>
and undef and NAN is the only thing that does not equal itsself
<tgschultz>
is this a comptime undef? as in the undefined type?
<scientes>
(only if you never hit llvm)
<scientes>
yeah bin_op doesn't take undefs currently
<scientes>
ran accross that while fixing something else
<scientes>
like > = !=
<scientes>
hmm, in godbolt is seems to work
<scientes>
guess i will have to look at it some more
<scientes>
yeah its generating code for a comptime variable