ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
steveno has joined #zig
steveno has quit [Ping timeout: 250 seconds]
porky11 has quit [Quit: Leaving]
<oats> if I call @import(), but don't assign its result, will the contents of the path be loaded into the current namespace, instead of its own?
<andrewrk> oats, if you want that behavior you can use this syntax: `use @import("foo.zig")`
<oats> ah, thanks!
<daurnimator> Is there some sort of magic variable that contains the current
<daurnimator> 'struct'
<daurnimator> i.e. where `foo()` and `` are the same thing
<knebulae> daurnimator: is @This not what you're looking for?
<daurnimator> knebulae: does @This work at the file scope?
<daurnimator> to me I think the model of "a file is just a struct" makes the most sense.
<knebulae> daurnimator: I don't know
<andrewrk> daurnimator, @This works at file scope
<daurnimator> andrewrk: great :)
<andrewrk> it will make more sense why it works once is implemented
<daurnimator> ah great
<knebulae> Q for anyone: I have an object that contains a bunch of function pointers. I am attempting to call the functions, and I have done so via standard dot notation, and when that didn't work, by defining a signature object and trying to assign the pointer contained in the object to it. The object is not opaque, as the definition of its field layout is indeed included within the C import. Zig complains that the type does not support field access.
<andrewrk> knebulae, can you elaborate on "when that didn't work?" at the beginning?
<andrewrk> it works for me
<knebulae> andrewrk: I got the same error (does not support field access).
<andrewrk> I need more information in order to help you
<daurnimator> andrewrk: the alternative of course is where file contents are a function body
<knebulae> andrewrk: the gBS object is the one in question
Ichorio has quit [Ping timeout: 245 seconds]
<andrewrk> knebulae, I can't run your code because it depends on files that I don't have. where is gBS defined?
<andrewrk> perhaps you could make a Short, Self Contained, Correct, Example
<knebulae> andrewrk: within the edk-II code (it's part of the VisualUefi project)
<knebulae> andrewrk: ok; I don't exactly have access to any random platform code that is passing in function pointers in this manner. :/
<andrewrk> even just the full error message would be helpful - I'm pretty sure "does not support field access" is not including several clues that could help me help you
<knebulae> andrewrk: error G7D2AEADC: type '?[*]EFI_BOOT_SERVICES' does not support field access
<andrewrk> ok so the type is an optional pointer of unknown length to EFI_BOOT_SERVICES
<andrewrk> the compiler is correct; such type does not support field access
<andrewrk> so why should there be field access? I'm guessing that this was auto-translated from C, and in fact should be a non-optional pointer to a single EFI_BOOT_SERVICES, which would support field access.
<andrewrk> relevant is this issue: which would have made it "just work", and as a workaround for now you can use gBS.?[0].GetMemoryMap
<knebulae> andrewrk: bingo. C import.
<daurnimator> andrewrk: did you see my vararg question last night?
<daurnimator> andrewrk: i.e. how can I call va_start from zig?
<andrewrk> It's in my high-priority 0.4.0 list
<daurnimator> andrewrk: okay. what is your plan for making it work? new builtin?
<andrewrk> daurnimator, yes probably builtins that map directly to the llvm builtins
<daurnimator> andrewrk: do you intend that zig is tied to LLVM long term/forever?
<daurnimator> andrewrk: just curious, as I ran into some confusion yesterday as I had to use LLVM-specific inline assembler annotations.
<andrewrk> not necessarily. the language specification will not depend on LLVM. however in practice I don't foresee ever escaping it as a dependency
<andrewrk> I do foresee zig implementing its own assembler that integrates better into the rest of the language
<andrewrk> for example, for x86_64, something closer to NASM
<andrewrk> often the zig builtins map directly to llvm builtins simply because LLVM got the abstraction correct
<daurnimator> okay
<daurnimator> so many things to do! :P
<knebulae> andrewrk: hey man, I really am sorry to ask these questions. I've attempted to follow your guidance, and it's infuriating. This is the error now: expected type 'extern fn(?[*]c_ulonglong, ?[*]EFI_MEMORY_DESCRIPTOR, ?[*]c_ulonglong, ?[*]c_ulonglong, ?[*]c_uint) c_ulonglong', found '?extern fn(?[*]c_ulonglong, ?[*]EFI_MEMORY_DESCRIPTOR, ?[*]c_ulonglong, ?[*]c_ulonglong, ?[*]c_uint) c_ulonglong' I can see no way to make the function pointer type an
<knebulae> optional.
<knebulae> andrewrk: otherwise the expected and found signatures are identical.
<andrewrk> knebulae, I think this is a good reason that I should prioritize #1059. The best workaround right now would be to use `zig translate-c` and then edit the prototypes to be better, and then commit that to your project
<andrewrk> knebulae, in this particular case I think you can append a `.?` to your function pointer to make it *not* an optional, which is what you need
<andrewrk> on examination I think this actually is not a case of the c translation picking unfortunate pointer types. I think this is a classic optional situation where you have a value that could be null, but you're trying to pass it where a value that cannot be null is expected
<andrewrk> so actually do not append `.?` to your function pointer unless you wish to assert that it is impossible that it could be null here
<knebulae> andrewrk: ok. I am fairly certain the the uefi boot services table pointer will not be null when running code written for a uefi environment.
<andrewrk> in this case use .?
<andrewrk> indeed this is something you could improve with hand-editing the translated header files
<knebulae> andrewrk: I want to avoid that inasmuch as possible.
<andrewrk> that's fair. interacting with auto-translated C code results in a lot of non-null assertions, since all C pointer types could be null
<knebulae> andrewrk: understood. I'm giving some consideration to #1059.
<knebulae> andrewrk: what exactly was I supposed to append the .? to? You said the function pointer, but it doesn't want to seem to take that syntax anywhere.
<andrewrk> the error message you got was `expected T, found ?T`, pointing at an expression in your code. you need to append `.?` to the expression
<knebulae> andrewrk: the compiler does not want to unwrap the value to match the expected function signature. Unable to evaluate constant expression error. Either way, I think the easiest, and perhaps cleanest way to address #1059 would be to have an override keyword of sorts, simply allowing us to provide a known-good function signature in zig terms without having to edit autogenerated C. That has so many downsides I don't even know where to start.
steveno has joined #zig
<andrewrk> knebulae, `unable to evaluate constant expression` makes me suspicious that there's something else going on here
<knebulae> andrewrk: something like @overrideCSig(symbol, signature)
<knebulae> andrewrk: @cOverride
<knebulae> andrewrk: maybe so. I can't seem to declare the pointer as optional, and I can't make the function pointer itself non-optional. :/
<knebulae> andrewrk: so the assignment expression always fails.
<andrewrk> I still think it would be helpful for both of us if you created a simple self-contained zig file to explore the problems you're running into
<andrewrk> put the relevant auto generated code in it, put the code you're trying to write into it, and then if you get an error it's easier to ask for help
<andrewrk> as is, I'm pretty sure you're making a simple mistake but it's opaque to me what's going on so I can't offer assistance
<andrewrk> (not to blame you, zig has a lot of rough edges in its current state)
<knebulae> andrewrk: no problem; I'm sure I'm doing something foolish too.
<knebulae> andrewrk: 2nd unwrapping operation within an expression not permitted, by chance?
<knebulae> uefi.clib.gBS.?[0].GetMemoryMap.? as an example
steveno_ has joined #zig
steveno has quit [Ping timeout: 250 seconds]
<daurnimator> knebulae: I don't see why not.
btbytes has joined #zig
<knebulae> andrewrk: maybe this will show you how I get into that catch-22 situation with never getting both sides of the expression to balance (?T=T or T=?T, but unable to evaluate constant expression when T=T or ?T=?T):
<knebulae> andrewrk: hopefully this is less daunting that the sh*t I have going :)
<knebulae> *than
<daurnimator> knebulae: you probably want: pub var A: FnAPrototype = clib.sExample.?[0].FunctionA.?;
<daurnimator> c`
<knebulae> and that should work. I've cleaned up the signatures a bit in the example. You can see that what *should* work (unwrapping the pointer to make it not an optional), now results in an "unable to evaluate constant expression" error.
<knebulae> Well, I figured it out in the isolated example, and it has to do with lazy binding.
<knebulae> So, now to figure out how to rectify the issue with a much larger underlying library.
redj has quit [Read error: Connection reset by peer]
<daurnimator> knebulae: is that ptrCast really required?
<knebulae> daurnimator: the compiler complains without it
<daurnimator> knebulae: what error?
<knebulae> daurnimator: error: expected type '?[*]u32', found '*u32'
steveno_ has quit [Quit: Leaving]
<daurnimator> knebulae: ah okay then. yes that is indeed this issue:
<daurnimator> knebulae: FWIW you shouldn't need the ? in the cast.
MajorLag has quit [Ping timeout: 246 seconds]
<daurnimator> you're really casting from * to [*].
<knebulae> daurnimator: dude, I'm like a pocket full of edge cases. fml.
<daurnimator> andrewrk: why isn't casting from [*] to * implicit?
<knebulae> daurnimator: understood on the cast
<daurnimator> andrewrk: isn't casting from "one item" to "unknown number of items" always going to be safe?
<daurnimator> knebulae: zig is young. I hit 10 edge cases for every file of zig I write
<knebulae> daurnimator: this is very similar to my other issue of optionals when interacting with auto imported c-code.
<daurnimator> uh, my above comment should have been: * to [*] implicit
<daurnimator> and I think the answer is that for * you can have an unknown size type. for [*] you need to know the size.
<daurnimator> oh I see my question is part of 1059
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<knebulae> daurnimator: has the function pointers working properly now. I'm still not sure what causes the behavior I was experiencing.
<daurnimator> knebulae: if you fix your extern declaration there you wouldn't need the casts...
<knebulae> daurnimator: If I change the prototype, the compiler complains about a type mismatch when I attempt to assign the function pointer provided by EFI.
<daurnimator> knebulae: oh, you're using cImport?
<knebulae> daurnimator: not type mismatch, just a type signature mismatch; expected x, got y...
<daurnimator> knebulae: then you don't need your own prototype at all...
<knebulae> daurnimator: yes
<knebulae> daurnimator: if I don't use a prototype, when I attempt to assign the fn ptr, say var x = blah;, I also get a function signature mismatch error.
<scientes> that is awesome that the stack trace code works both in freestanding mode and with an OS
_whitelogger has joined #zig
hooo has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #zig
_whitelogger has joined #zig
_whitelogger has joined #zig
errpr has quit [Ping timeout: 264 seconds]
porky11 has joined #zig
hooo has joined #zig
qazo has quit [Ping timeout: 240 seconds]
Ichorio has joined #zig
<knebulae> andrewrk: to answer your question from before about the uefi environment, the runtime is essentially 2 tables worth of function and variable pointers. The problem is that gnu exposed certain functions one way, Intel another. :/ But the underlying implementations are there regardless of how the C libraries expose them. So this ( is possible without a library.
<knebulae> *without edk-II or gnu-efi.
_whitelogger has joined #zig
Zaab1t has quit [Quit: bye bye friends]
<knebulae> andrewrk: so I'm torn; continue on my path using edk-II as a dependency, or write my own native zig uefi library. On the one hand, for my needs, it will duplicate a lot of code. On the other hand, it would tie up a few loose ends with zig itself, and it would also completely remove the dependency on C.
btbytes has joined #zig
<knebulae> on - @ptrToMany would work, as the compiler is already forcing me to cast most pointers anyway; The implicit casting from *T to [*]T is the easiest, but is very dangerous. Does zig have any support for annotation/attributes?
errpr has joined #zig
<knebulae> what does the underscore represent? is it an anonymous variable/type/method?
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
btbytes has joined #zig
<andrewrk> knebulae, it represents a "black hole" that you can send values into
<knebulae> so like ignoring the return value without generating a compiler error
<andrewrk> precisely
SimonNa has quit [Remote host closed the connection]
porky11 has quit [Ping timeout: 250 seconds]
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
btbytes has joined #zig
vegecode has joined #zig
<vegecode> quick question? Where did the numbers come from in the function zig_llvm_fn_key_hash? I'm trying to add the bitreverse intrinsic and failing.
<andrewrk> vegecode, literally random
<andrewrk> the hashing is pretty bad, probably could be vastly improved
<vegecode> It keeps giving the behavior of the bswap intrinsic...
<andrewrk> that probably meanst hat zig_llvm_fn_key_eql is wrong
<andrewrk> or that you accidentally did = ZigLLVMFnIdBswap;
<vegecode> They both look correct to me. Thanks for the reply.
<andrewrk> vegecode, in this case I think the best bet is to create a very simple file (have you seen the build-obj trick with panic handler?) and step through the code when it chooses the llvm function name
<vegecode> Ok. I will try that after work. Thanks a bunch.
vegecode has quit [Quit: WeeChat 2.2]
btbytes has quit [Quit: Textual IRC Client:]
fsateler_ has quit [Quit: ZNC 1.7.1+deb2 -]
fsateler has joined #zig
porky11 has joined #zig
vegecode has joined #zig
vegecode has quit [Client Quit]
ForLoveOfCats has joined #zig
porky11 has quit [Ping timeout: 250 seconds]
<ForLoveOfCats> The docs state that characters are stored in unsigned 8 bit integers yet it also states that unfettered use of UTF-8 in strings is allowed. How is this possible when many Unicode points require multiple 8 bit ints to store? Are arrays just smart enough to handle this?
<andrewrk> ForLoveOfCats, most operations can be done directly on encoded UTF-8 data
<andrewrk> arrays are just arrays