01:16 <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?

01:18 <andrewrk> oats, if you want that behavior you can use this syntax: `use @import("foo.zig")`

01:18 <oats> ah, thanks!

01:22 <daurnimator> Is there some sort of magic variable that contains the current

01:22 <daurnimator> 'struct'

01:23 <daurnimator> i.e. where `foo()` and `@current_struct_scope.foo()` are the same thing

01:24 <knebulae> daurnimator: is @This not what you're looking for?

01:24 <daurnimator> knebulae: does @This work at the file scope?

01:24 <daurnimator> to me I think the model of "a file is just a struct" makes the most sense.

01:25 <knebulae> daurnimator: I don't know

01:42 <andrewrk> daurnimator, @This works at file scope

01:42 <daurnimator> andrewrk: great :)

01:42 <andrewrk> it will make more sense why it works once https://github.com/ziglang/zig/issues/1047 is implemented

01:43 <daurnimator> ah great

01:50 <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.

01:51 <andrewrk> knebulae, can you elaborate on "when that didn't work?" at the beginning?

01:52 <andrewrk> it works for me

01:52 <knebulae> andrewrk: I got the same error (does not support field access).

01:53 <andrewrk> I need more information in order to help you

01:53 <knebulae> andrewrk: https://github.com/nebulaeonline/nebulae/blob/master/k/src/kmem.zig

01:54 <daurnimator> andrewrk: the alternative of course is where file contents are a function body

01:55 <knebulae> andrewrk: the gBS object is the one in question

01:58 <andrewrk> knebulae, I can't run your code because it depends on files that I don't have. where is gBS defined?

01:58 <andrewrk> perhaps you could make a Short, Self Contained, Correct, Example http://www.sscce.org/

01:59 <knebulae> andrewrk: within the edk-II code (it's part of the VisualUefi project)

02:01 <knebulae> andrewrk: ok; I don't exactly have access to any random platform code that is passing in function pointers in this manner. :/

02:02 <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

02:03 <knebulae> andrewrk: error G7D2AEADC: type '?[*]EFI_BOOT_SERVICES' does not support field access

02:04 <andrewrk> ok so the type is an optional pointer of unknown length to EFI_BOOT_SERVICES

02:04 <andrewrk> the compiler is correct; such type does not support field access

02:05 <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.

02:06 <andrewrk> relevant is this issue: https://github.com/ziglang/zig/issues/1059 which would have made it "just work", and as a workaround for now you can use gBS.?[0].GetMemoryMap

02:06 <knebulae> andrewrk: bingo. C import.

02:09 <daurnimator> andrewrk: did you see my vararg question last night?

02:09 <daurnimator> andrewrk: i.e. how can I call va_start from zig?

02:10 <daurnimator> relevant code: https://github.com/ziglang/zig/pull/1863/files#diff-0ee24f1c4ac5c34c9f63bfd3230c4008R144

02:10 <andrewrk> daurnimator, https://github.com/ziglang/zig/issues/515

02:10 <andrewrk> It's in my high-priority 0.4.0 list

02:12 <daurnimator> andrewrk: okay. what is your plan for making it work? new builtin?

02:13 <andrewrk> daurnimator, yes probably builtins that map directly to the llvm builtins

02:13 <daurnimator> andrewrk: do you intend that zig is tied to LLVM long term/forever?

02:14 <daurnimator> andrewrk: just curious, as I ran into some confusion yesterday as I had to use LLVM-specific inline assembler annotations.

02:14 <andrewrk> not necessarily. the language specification will not depend on LLVM. however in practice I don't foresee ever escaping it as a dependency

02:15 <andrewrk> I do foresee zig implementing its own assembler that integrates better into the rest of the language

02:15 <andrewrk> for example, for x86_64, something closer to NASM

02:15 <andrewrk> often the zig builtins map directly to llvm builtins simply because LLVM got the abstraction correct

02:20 <daurnimator> okay

02:20 <daurnimator> so many things to do! :P

02:46 <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

02:46 <knebulae> optional.

02:47 <knebulae> andrewrk: otherwise the expected and found signatures are identical.

02:47 <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

02:49 <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

02:51 <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

02:51 <andrewrk> have a look: https://ziglang.org/documentation/master/#Optionals

02:52 <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

02:53 <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.

02:53 <andrewrk> in this case use .?

02:54 <andrewrk> indeed this is something you could improve with hand-editing the translated header files

02:54 <knebulae> andrewrk: I want to avoid that inasmuch as possible.

02:55 <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

02:55 <knebulae> andrewrk: understood. I'm giving some consideration to #1059.

03:11 <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.

03:12 <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

03:30 <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.

03:31 <andrewrk> knebulae, `unable to evaluate constant expression` makes me suspicious that there's something else going on here

03:31 <knebulae> andrewrk: something like @overrideCSig(symbol, signature)

03:31 <knebulae> andrewrk: @cOverride

03:32 <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. :/

03:32 <knebulae> andrewrk: so the assignment expression always fails.

03:33 <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

03:33 <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

03:34 <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

03:34 <andrewrk> (not to blame you, zig has a lot of rough edges in its current state)

03:35 <knebulae> andrewrk: no problem; I'm sure I'm doing something foolish too.

03:55 <knebulae> andrewrk: 2nd unwrapping operation within an expression not permitted, by chance?

03:56 <knebulae> uefi.clib.gBS.?[0].GetMemoryMap.? as an example

04:02 <daurnimator> knebulae: I don't see why not.

05:05 <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): https://github.com/nebulaeonline/ZigTesting

05:05 <knebulae> andrewrk: hopefully this is less daunting that the sh*t I have going :)

05:05 <knebulae> *than

05:17 <daurnimator> knebulae: you probably want: pub var A: FnAPrototype = clib.sExample.?[0].FunctionA.?;

05:18 <daurnimator> c`

05:21 <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.

05:22 <knebulae> https://github.com/nebulaeonline/ZigTesting/blob/master/src/main.zig

05:35 <knebulae> Well, I figured it out in the isolated example, and it has to do with lazy binding.

05:35 <knebulae> So, now to figure out how to rectify the issue with a much larger underlying library.

06:00 <daurnimator> knebulae: is that ptrCast really required?

06:01 <knebulae> daurnimator: the compiler complains without it

06:01 <daurnimator> knebulae: what error?

06:02 <knebulae> daurnimator: error: expected type '?[*]u32', found '*u32'

06:04 <daurnimator> knebulae: ah okay then. yes that is indeed this issue: https://github.com/ziglang/zig/issues/1059

06:04 <daurnimator> knebulae: FWIW you shouldn't need the ? in the cast.

06:04 <daurnimator> you're really casting from * to [*].

06:04 <knebulae> daurnimator: dude, I'm like a pocket full of edge cases. fml.

06:05 <daurnimator> andrewrk: why isn't casting from [*] to * implicit?

06:05 <knebulae> daurnimator: understood on the cast

06:05 <daurnimator> andrewrk: isn't casting from "one item" to "unknown number of items" always going to be safe?

06:06 <daurnimator> knebulae: zig is young. I hit 10 edge cases for every file of zig I write

06:07 <knebulae> daurnimator: this is very similar to my other issue of optionals when interacting with auto imported c-code.

06:09 <daurnimator> uh, my above comment should have been: * to [*] implicit

06:10 <daurnimator> and I think the answer is that for * you can have an unknown size type. for [*] you need to know the size.

06:11 <daurnimator> oh I see my question is part of 1059

06:19 <knebulae> daurnimator: https://github.com/nebulaeonline/nebulae/blob/master/k/src/kmem.zig has the function pointers working properly now. I'm still not sure what causes the behavior I was experiencing.

06:22 <daurnimator> knebulae: if you fix your extern declaration there you wouldn't need the casts...

06:23 <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.

06:24 <daurnimator> knebulae: oh, you're using cImport?

06:24 <knebulae> daurnimator: not type mismatch, just a type signature mismatch; expected x, got y...

06:24 <daurnimator> knebulae: then you don't need your own prototype at all...

06:24 <knebulae> daurnimator: yes

06:25 <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.

06:36 <scientes> that is awesome that the stack trace code works both in freestanding mode and with an OS

11:47 <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 (https://github.com/ziglang/zig/issues/1858) is possible without a library.

11:48 <knebulae> *without edk-II or gnu-efi.

13:46 <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.

14:27 <knebulae> on https://github.com/ziglang/zig/issues/1059 - @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?

14:55 <knebulae> what does the underscore represent? is it an anonymous variable/type/method?

16:19 <andrewrk> knebulae, it represents a "black hole" that you can send values into

16:21 <knebulae> so like ignoring the return value without generating a compiler error

16:22 <andrewrk> precisely

20:24 <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.

20:25 <andrewrk> vegecode, literally random

20:25 <andrewrk> the hashing is pretty bad, probably could be vastly improved

20:26 <vegecode> It keeps giving the behavior of the bswap intrinsic...

20:27 <andrewrk> that probably meanst hat zig_llvm_fn_key_eql is wrong

20:28 <andrewrk> or that you accidentally did key.id = ZigLLVMFnIdBswap;

20:30 <vegecode> They both look correct to me. Thanks for the reply.

20:33 <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

20:34 <andrewrk> https://gist.github.com/andrewrk/5684434a2a8d4cbb08bb0d855c4f2ada

20:34 <vegecode> Ok. I will try that after work. Thanks a bunch.

23:35 <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?

23:56 <andrewrk> ForLoveOfCats, most operations can be done directly on encoded UTF-8 data

23:57 <andrewrk> arrays are just arrays