ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
Ichorio has quit [Read error: Connection reset by peer]
kristate has joined #zig
suirad has joined #zig
<suirad>
Howdy all. anyone around that could point me in the right direction with my build.zig?
<suirad>
I couldnt find a good example of anyone doing something similar. my project is structured as so: ./src/main.zig, ./deps/<subrepo>/src/<library>.h
<suirad>
how do i setup my build.zig so that in my main.zig i can just do a @cImport("library.h")?
rohlem_ has joined #zig
jevinskie has joined #zig
<rohlem_>
andrewrk: I spent the last hour writing an overly-long comment on #1953 (null pointers etc.), seems like I just missed you. Please consider reading at least the first summary paragraph and asking questions if I something is unintelligible.
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 272 seconds]
<suirad>
also, if i am using build.zig, how do I #define something for the see code to see from the build.zig
<suirad>
ahh found it, builder.compileFlags
<suirad>
err object.compileFLags rather
<emekankurumeh[m]>
what's the zig version of c bitflags?
<rohlem_>
emekankurumeh[m]: I think you mean "bitfields"? You would just use the corresponding "uX" and "iX" types in Zig, I think. Packed/exported if you specially care about layout.
kristate has quit [Remote host closed the connection]
kristate has joined #zig
<emekankurumeh[m]>
no, I mean bitflags for calls to functions like socket
kristate has quit [Remote host closed the connection]
kristate has joined #zig
<rohlem_>
emekankurumeh[m]: Oh. I think you could introduce an enum for the specific "set" flag states, and use its underlying (probably unsigned) integer type for values, like you would in C.
<rohlem_>
emekankurumeh[m]: Alternatively, you could make it into a struct of "u1" members and set those to 0/1 to indicate clear/set state. Doesn't allow the same smooth bit operator tricks, but is probably harder to misuse.
<rohlem_>
(again, packed if you care about layout/size)
<suirad>
if you do it as a union, you could still also do the bit operator stuff
<emekankurumeh[m]>
what if turned error sets into general purpose sets with error sets just being one use?
<rohlem_>
suirad: It should work as a export-C-union (explicitly requesting no hidden tag field). Note that relevant aliasing rules are still up for debate later on (see issue #1643 - currently all aliasing is supported).
<rohlem_>
emekankurumeh[m]: What other use cases could you think of? Error sets actually require a bit of compiler magic to gather error codes from everywhere, figure out the necessary type - some of that behaviour is still unspecified.
<rohlem_>
If the underlying "set hierarchy" structure is of interest to you, I think a (standard) library solution is a reasonable proposal.
<rohlem_>
andrewrk: I now more concisely summarized my thoughts as counter-proposal #1959 ; it's probably more readable, but if you feel something is left out, the original comment went into *a little* more detail.
rohlem_ has quit [Quit: test]
<emekankurumeh[m]>
i made a set type a while back, but i have no idea how deal with enums with custom ordinal values.
<forgot-password>
andrewrk: Thanks, what's the current status on that?
<andrewrk>
forgot-password, probably going to be closed
<andrewrk>
feel free to make a case for it in the issue, of course
<forgot-password>
By closed you mean: Not going to be implemented?
phvse has joined #zig
<rohlem>
andrewrk: If #1953 is still on your mind / whenever you get to it, if my last comment still failed to get my point across, feel free to ask more direct questions here, if you want.
<andrewrk>
rohlem, I just replied
<phvse>
Hi, I'm trying to understand how the Zig IR is obtaining symbols from other files. IrInstructionCall contains a pointer to fn_ref but I'm having trouble finding out what IrInstruction refers to a *thing*, be it a struct or function or something.
<andrewrk>
hi phvse. look for calls to `find_decl`
rohlem_ has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rohlem_>
andrewrk: Want me to reply over there or try being shorter here to make follow-up questions easier?
<andrewrk>
let's chat here for a bit
<emekankurumeh[m]>
was `@reify` planned to work at runtime or would it be a comptime construct?
hg has joined #zig
<andrewrk>
emekankurumeh[m], comptime
<rohlem_>
The use case outlined in that issue, operating on address 0, is not an issue for non-optional Zig pointers.
jevinskie has joined #zig
rohlem has quit [Ping timeout: 256 seconds]
<rohlem_>
The only corner case that would actually throw us for a loop would be saving this value in an optional Zig pointer, because we already overload the value for "unpopulated".
<rohlem_>
Is there a reason why non-optional Zig pointers should special-case a specific value, say address 0 ?
<andrewrk>
yes, on non-freestanding targets, 0 is always invalid, and therefore an available representation of "null" for optionals
<rohlem_>
I understood the issue to be "we want to be able handle 0 like a normal address". So I propose we do just that for non-optional pointers.
<andrewrk>
this also opens up optimization opportunities in LLVM with its "nonnull" attribute
<andrewrk>
we want to be able to handle 0 like a normal address, in freestanding mode, if the mappable-0-address build option is enabled
<phvse>
Does the LLVM define a "null" pointer as being pointed at zero?
<rohlem_>
Correct. And I don't think adding allowzero to the type system, so that code has to juggle allowzero and non-allowzero, actually helps in development anywhere.
<andrewrk>
phvse, yes, currently it is always zero, however some community members have expressed interest in a future version allowing the invalid pointer value to be specified in the data layout string
<rohlem_>
(more than it complicates things, anyway)
<andrewrk>
rohlem_, the use case I linked is currently invoking undefined behavior. doing the `allowzero` proposal will make it instead cause a compile error, and then using `allowzero` will fix it to not have undefined behavior
<phvse>
Is the issue that you want a nullable pointer type that can also refer to address 0?
<rohlem_>
What I propose is basically that all optional pointers are non-allowzero, and all non-optional pointers are allowzero by default.
<andrewrk>
phvse, yes, the problem is that library code, for example, may rely on the property that casting T to ?T results in a non-null value
<phvse>
Doesn't allowing zero by default remove type safety?
<andrewrk>
explain?
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<phvse>
@rholem's proposal of "all non-optional pointers are allowzero by default"
<phvse>
would that not remove some type safety from regular pointers?
<rohlem_>
phvse: "regular" as in non-optional pointers do not inherently have invalid addresses (on all theoretical targets).
<rohlem_>
phvse: The same way all bit representations of u8 are valid.
<phvse>
okay that makes sense
<rohlem_>
andrewrk: My pragmatic solution/suggestion for finding an unused/invalid address to signal "unpopulated" under freestanding: Allocate a single byte for this specific purpose.
<rohlem_>
This "null byte" would be used as "unreachable address" instead of address 0, and we get all the same benefits.
<andrewrk>
phvse, that's right, for example there's going to be a really helpful safety-checked undefined behavior on implicit cast from C pointer to Zig pointer
<andrewrk>
which works because 0 is not a valid address
<rohlem_>
That safety check makes sense when casting from any optional pointer (Zig or C) to any non-optional pointer.
<andrewrk>
rohlem_, that's an interesting proposal - a compile option to choose the invalid pointer address value
<rohlem_>
I don't know whether the invalid address we check for is 0 or some arbitrary other value doesn't have too huge performance implications.
forgot-password has quit [Quit: leaving]
<rohlem_>
If it actually does, that's just more reason for freestanding targets to also vouch for address 0 to be their invalid address.
<rohlem_>
But since it's up to their implementation, having the option gives the most flexibility.
<andrewrk>
vouching for address 0 to be invalid in freestanding is indeed desired and that's why allowzero is helpful - for example in my kernel linked above, it only uses allowzero once to copy some bytes, and then all other pointers in the codebase have 0 as invalid address
<rohlem_>
andrewrk: this "allowzero" pointer is incompatible with the entire rest of the code base however.
<andrewrk>
correct
<rohlem_>
I would rather propose that non-optional pointers are _always "allowzero"-enabled.
<rohlem_>
The type system already gives us checks anytime we convert between non-optional and optional.
<andrewrk>
if allow zero is enabled then why would pointer casting do any checks on null?
<rohlem_>
Because "unpopulated" and "the one address we chose" are different values, even if their representations (in incompatible types for this value) line up.
<rohlem_>
The same way i8(-128) and u8(255) aren't "the same value"
<andrewrk>
you're saying optional pointers would not support address zero
<rohlem_>
That is why, on conversion, the type system helps us by checking if we're doing something sensible. Turning "no address" (unpopulated optional) into "a special address we only use in edge cases" is not sensible behaviour.
<andrewrk>
so if you have a pointer with address zero, and cast it to an optional, you mangle information
<rohlem_>
andrewrk: Yes, they would not support this one address we reserved for this special purpose and only use in kernel code via non-optional pointers.
<rohlem_>
Again, doesn't have to be 0.
<rohlem_>
(if we make it configurable9
<andrewrk>
I do think you're onto something with configurable invalid pointer address
<emekankurumeh[m]>
the freebsd ci still pulls from the master branch
<andrewrk>
emekankurumeh[m], you would have had to rebase onto master
<rohlem_>
andrewrk: In my mind there would be even simpler solutions than reserving a global byte value, f.e. taking the very first stack address (can be implemented in bootstrap code with a single push and then forgotten about), or maybe using some offset into const compiled function data that will never be read by code.
<MajorLag>
andrewrk: did we already have an issue for configurable "invalid" values for optionals? I feel like it has come up before.
<andrewrk>
MajorLag, not that I remember
<rohlem_>
But we always use some trick to guarantee this address / pointer representation never comes up otherwise, just like the C standard guarantees for null pointers.
<andrewrk>
it's a decent solution though, I would just set it to 0xffffffffffffffff in clashos
<andrewrk>
it breaks people's code who use memset to set everything to zero, but we've been discouraging that for a long time now
<emekankurumeh[m]>
instead of memset are we supposed to use `undefined`?
<andrewrk>
if you use memset, every value becomes undefined, unless the type is specified to have a well-defined 0 bit pattern
<rohlem_>
andrewrk: That code was only C-compliant on platforms whose C-ABI uses 0 as null pointer representation before. Since freestanding has no C-ABI, null pointers need to be defined by freestanding systems themselves. If they're defined to be 0, memset still works the same.
<andrewrk>
emekankurumeh[m], if you want something to be a particular value, then you have to assign that value
<andrewrk>
rohlem_, one more consideration. does gcc or clang allow specifying the null value?
<andrewrk>
I don't think it does. clang's stddef.h has #define NULL (void *) 0
<rohlem_>
andrewrk: That is not the representation, that is the C language definition of null pointers.
<andrewrk>
so if your freestanding project mixed C code and Zig code, your zig code with invalid address configured to be non-zero would be incompatible
<rohlem_>
andrewrk: A 0-valued integer cast to pointer type gives you the null value.
<andrewrk>
oh I see
<andrewrk>
how do you get address 0 in C then?
<rohlem_>
andrewrk: If a platform's ABI has a different null value representation, the compiler fills that in (same for usage as conditions etc.)
<rohlem_>
andrewrk: I did link to this in my original comment: http://c-faq.com/null/accessloc0.html -- Basically, "ask your implementation" on what trick works, it might make an exception if it understands this memset-to-0 code pattern.
<rohlem_>
Similar to how type-punning in C is sort-of-unintuitively based on whether your compiler understands what you're doing or not.
<Flaminator>
What is the preferred way to replace #define/#ifdef/#ifndef/#if defined()? Can't really find anything in the documentation about it. These are only really used for different configurations.
<rohlem_>
There are a couple of misalignments from the solution proposed there to my understanding of the issue.
<andrewrk>
Flaminator, with zig's comptime features!
<andrewrk>
Flaminator, `if` and `switch` implicitly happen at compile-time if the condition/target expression is comptime known
<andrewrk>
and anything in global scope is implicitly comptime
<andrewrk>
and @import("builtin") to find out endianness, OS, architecture, etc. see `zig builtin` for what's available in @import("builtin")
<andrewrk>
if you're looking to specify additional build options I can guide you on that
<rohlem_>
andrewrk: I think I'm still not convinced that extending the pointer type system by "allowzero" is a worth the effort involved, since it is such an exotic use case, and breaks code reuse around these parts even within a kernel's code base... But with you as the (current) only user and implementor, you're probably in the single best position to judge that cost-effect-ratio.
<rohlem_>
My main point was that it doesn't make sense in the context of the type system, or when reasoning "ordinary operation semantics". It's just this really really fragile special case tool, similar to volatile pointers.
<rohlem_>
No library or otherwise reusable code should ever need/want allowzero. But if it's the cleanest way to implement this special case, and the LLVM nonzero-attribute turns out to be valuable for code everywhere else, I guess there's not much arguments against it.
<rohlem_>
Using ordinary pointer types with special builtin functions probably looks even messier than expanding the pointer type matrix.
<andrewrk>
rohlem_, I completely agree with this: No library or otherwise reusable code should ever need/want allowzero.
<rohlem_>
And while it might be surprising for the dozen freestanding developers that ever _want to access address 0, if it's easy to find in the documentation, it might be the best solution for this use case. But it shouldn't affect into "ordinary code", if at all possible.
<andrewrk>
given that `allowzero` will be a compile error, I think it's safe to say that it shouldn't effect "ordinary code"
<andrewrk>
*a compile error on non freestanding targets
<andrewrk>
*affect
<rohlem_>
Yes, I suppose that's a reasonable warning/stop sign.
<andrewrk>
emekankurumeh[m], want to rebase your pull request on master and see if the freebsd ci works?
darithorn has joined #zig
<Flaminator>
I am trying to do http://aeug.eu/p/223d.c I am just not sure how to handle the absence of any of my defines.
<schme245>
to ensure that there is no fn call overhead
<andrewrk>
is this a performance concern or do you have a semantic reason for avoiding the call frame?
<schme245>
for performance, I haven't done any benchmarks or anything, just curious if it's possible to sidestep the fn call in the same way that a C macro would
<MajorLag>
usually you'd just let the optimizer get it, but you can explicitly mark it inline and, unlike in C, that isn't a suggestion to the compiler. It will throw an error if it cannot inline it for some reason.
<MajorLag>
you can also use @inlineCall to enforce any arbitrary function be inlined.
<schme245>
great! I don't think the `inline` attribute for functions is mentioned in the docs, it's only mentioned in the context of inline for and while loops
<schme245>
I noticed that it could be used on functions but I didn't know what the semantics were, thanks for clarifying MajorLag
DutchGh0st has joined #zig
<DutchGh0st>
Are you guys subscribed to PewDiePie? if not, would you please do so? Tseries from India is catching up, and we can't let that happen obviously
<MajorLag>
No
<companion_cube>
quite obviously
<DutchGh0st>
If you want, please make it a yes MajorLag, it'd help a bit!
<andrewrk>
DutchGh0st, please stay on topic
<andrewrk>
no ads
<DutchGh0st>
Okey okey, sowrry, won't start about it again :)
<andrewrk>
(ads for something zig related would be an exception, within reason, e.g. a game somebody made in zig)
<knebulae>
@andrewrk: iron fist. even gave me a full and proper definition of a "clear and concise example" I'm like bro, it's a kernel, kinda hard to isolate :)
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
knebulae, hmm? what are you referring to?
<knebulae>
@andrewrk: that uefi stuff back in late December.
<knebulae>
@andrewrk: my questions weren't very "organized" :)
<andrewrk>
knebulae, I think your first message(s) got cut off? the first one I see starts with "iron fist"
<knebulae>
@andrewrk: the iron first was just in relation to the comments above referencing PewDiePie (or whoever).
<knebulae>
@andrewrk: the second part of the statement was an example of when you were like "look dude, enough babbling, questions!"
Ichorio has quit [Ping timeout: 245 seconds]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
hg has quit [Quit: WeeChat 2.3]
<emekankurumeh[m]>
andrewrk: do plan to be a BDFL for zig?
<andrewrk>
yes. with zig team members ready to take over in the event anything should happen to me
<Flaminator>
Will there be any stream tonight?
<andrewrk>
Flaminator, I think I'm going to cancel tonight, I feel behind on issues and stuff