<wink_>
@andrewrk, a while ago you said you had to "use the same compiler to build llvm, clang, and zig" (https://freenode.irclog.whitequark.org/zig/2018-09-24#23143159). IIRC, another time this came up you had a link with some additional information.
<wink_>
If my recolection is correct, do you still have that link?
darithorn has quit [Remote host closed the connection]
kristate has quit [Remote host closed the connection]
diltsman has joined #zig
fsateler has joined #zig
fsateler_ has quit [Ping timeout: 252 seconds]
allan0 has quit [Ping timeout: 245 seconds]
<diltsman>
What file is builtin.Arch in?
<andrewrk>
wink_, I don't remember, sorry
<andrewrk>
diltsman, `zig builtin` shows you the contents of @import("builtin")
<daurnimator>
huh... a see some sort of magic `__zig_test_fn_slice` in there
<andrewrk>
yeah that's a bit magic. has to do with how `zig test` is implemented.
<daurnimator>
andrewrk: wow; that musl merge is huge!
<daurnimator>
andrewrk: so I don't quite understand: why are we bundling musl?
wilsonk has quit [Read error: Connection reset by peer]
<daurnimator>
it does seem weird to me that my zig package now contains all the .c files for musl....
wilsonk has joined #zig
<daurnimator>
would it make more sense to include precompiled libc.a files for each target?
kristate has joined #zig
jjido has joined #zig
jjido has quit [Client Quit]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
Zaab1t has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Zaab1t has quit [Quit: bye bye friends]
dewf has joined #zig
kristate has quit [Remote host closed the connection]
develonepi3 has quit [Remote host closed the connection]
knebulae has joined #zig
<andrewrk>
gamester, what's the issue?
<gamester>
andrewrk: isn't there supposed to be a compile error when trying to pass an i32 to a function that takes a [*c]i32 ?
<gamester>
the function ends up interpreting the integer as a pointer
halosghost has joined #zig
<andrewrk>
[*c] pointers are dangerous
<andrewrk>
if should be an error if it would be an error in C
<andrewrk>
I just checked, in C it's allowed, but you get a warning
<andrewrk>
I think we can maybe tighten up the rules a bit
<gamester>
ah, I was under the mistaken impression that c pointers were introduced only to solve the issue of pointer-to-one vs pointer-to-many and perhaps null vs not-null
<gamester>
in auto translated code
<andrewrk>
gamester, their purpose is to have the same semantics as C pointers. I'm opening an issue for your example, just a sec
<gamester>
andrewrk: for me, gcc also complains by default: "incompatible integer to pointer conversion passing 'int' to parameter of type 'int *'; take the address with & [-Wint-conversion]"
<gamester>
(it's a warning)
<andrewrk>
gamester, right, so I think we can have an error for that. Thanks for the test case, and apologies for getting a little defensive at first :)
<gamester>
np
Zaab1t has joined #zig
<gamester>
It's interesting how default warnings change the C spec without changing it :)
nbjoerg has left #zig [#zig]
<gamester>
it seems to be a solution for modernizing such an old language without breaking anything
dewf has quit [Read error: Connection reset by peer]
<andrewrk>
yeah
<wink_>
andrewrk: Txs for trying to remember, let me ask more directly; why is zig broken when NOT using "the same compiler to build llvm, clang, and zig"?
<andrewrk>
clang and gcc have incompatible C++ ABIs across some combination of versions
<wink_>
txs!
man213 has joined #zig
man213 has quit [Quit: Page closed]
man213 has joined #zig
kristate has joined #zig
kristate has quit [Read error: Connection reset by peer]
kristate_ has joined #zig
<man213>
Hi guys. Newbie and grateful zig user here. Today I downloaded compiler master build (2019-03-12) and noticed that my program produces different results depending on build option: i.e. --release-safe and debug builds produce correct results, but --release-small and --release-safe produce incorrect result. I wonder if it is a known issue? Is there any simpler way to test this behaviour than my program (mine is a raytracer). I'm a windows
<andrewrk>
hi man213
Akuli has joined #zig
<andrewrk>
is your code open source?
<Akuli>
how am i supposed to run zig test under valgrind? in older zig versions, i could do 'valgrind zig-cache/test', but now it's something like 'valgrind zig-cache/o/oiasjfoaijsfioajsfio/test'
<andrewrk>
man213, what's std.winapi? do you have a patched zig standard library?
<man213>
andrewrk, damn, not really. I just placed slightly modified winapi bindings into zig's folder. Forgot to move it to my project's dir. Gonna fix it
develonepi3 has joined #zig
<man213>
andrewrk, fixed. Now everything should be fine
<andrewrk>
man213, is this a regression from a previous version of zig? was there a version where release-fast / release-small had expected behavior?
<man213>
andrewrk, I'm not sure. Just noticed it today. I upgrade the compiler from time to time (and upgraded it today) with master build and often do release-fast and release-small builds to check executable size before committing. Yesterday everything was ok.
<man213>
andrewrk, is there any previous master builds for me to check it or it is replaced completely by a newer master build?
<andrewrk>
oh - in your case @setRuntimeSafety should do the trick. you could try a release-fast build, with @setRuntimeSafety(true) in some places to see where it fixes it
<andrewrk>
I'm not suggesting this as a workaround, but to help discover the nature of the problem
<man213>
andrewrk, Just rolled back two commits earlier and release-fast build produces exactly the same result as the debug build. Hmm... Ok, I'll play with @setRuntimeSafety and do some more research. Thank you, Andrew.
<andrewrk>
man213, two commits earlier - what version is that?
<andrewrk>
in your own code or two versions of zig?
<man213>
andrewrk, two commits earlier - I meant my code, not zig
<andrewrk>
ah ok- in that case it's probably undetected undefined behavior. if you figure out what it is, I'm interested to know, because as far as zig is concerned we either need to (1) add runtime checks to detect that, or (2) document it as something zig cannot detect: https://github.com/ziglang/zig/issues/1966
<andrewrk>
(for (1) I mean runtime checks for Debug/ReleaseSafe builds)
<man213>
andrewrk, ok, I'll play with @setRuntimeSafety and other stuff in case if the issue is my fault and let You know.
<andrewrk>
what happens when you try to access it?
<man213>
andrewrk, Chrome says that this site can't be reached. Ping says that "ping: https://clbin.com/aesio: Name or service not known"
<andrewrk>
maybe you are experiencing DNS issues?
diltsman has quit [Ping timeout: 256 seconds]
<man213>
andrewrk, nevermind. Opened the link from the other machine. Maybe it's an issue with my VPN
kristate_ has quit [Remote host closed the connection]
<man213>
andrewrk, How @setRuntimeSafety should be used? Do I need to place it in the beginning of my function's body or something? (couldn't figure out it from the docs)
<andrewrk>
man213, I'll improve the docs and then see if that answers your question :)
jjido has joined #zig
mikdusan has quit [Remote host closed the connection]
<man213>
andrewrk, ok :)
<andrewrk>
man213, I found a bug - @setRuntimeSafety is not correctly overriding the build mode. pushing a fix shortly.
<man213>
andrewrk, fine, otherwise I was about to spray @setRuntimeSafety _everywhere_ :D
mikdusan has joined #zig
<andrewrk>
man213, it's probably going to take all day for this fix to make it through the CI
<andrewrk>
there's already a bit of a queue
<man213>
andrewrk, may be it's the good time for me to do a build myself
darithorn has joined #zig
<andrewrk>
daurnimator, the latest zig source tarball is still less than 5 MiB
<andrewrk>
consider that llvm-7.0.1.src.tar.xz + cfe-7.0.1.src.tar.xz is 39 MiB. That gives a rough estimate of how big zig-1.0.0-bootstrap.tar.xz will be, and the new musl source code is a tiny fraction of it
kristate has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
that new `error: dependency on library c must be explicitly specified in the build command` is nice
<Akuli>
yes, but that's not the error i'm getting
<Akuli>
:D
<andrewrk>
weird, if I don't link libc then I don't get the valgrind errors
<Akuli>
it seems to only happen with c_allocator
<Akuli>
if i replace it with DirectAllocator.init() and link with libc anyway, it will work
<andrewrk>
I'm getting the valgrind errors with --library c but the allocator line deleted
<Akuli>
:DDDD
<Akuli>
same
<Akuli>
but it works with DirectAllocator and --library c!
<Akuli>
adding the DirectAllocator fixes it
<andrewrk>
what do you mean adding it?
<Akuli>
replace the allocator line with that
<andrewrk>
so not even using it
<Akuli>
yes
<Akuli>
lets guess: something is calculating stack sizes or indexes or whatever incorrectly, and adding a large enough object on the stack happens to "fix" it so that valgrind doesn't notice that anything is wrong
<andrewrk>
this is either a bug in zig or a bug in valgrind
<Akuli>
i still don't know what --library c has to do with this
<Akuli>
it fixes it every time, somehow
<andrewrk>
it's the opposite for me. --library c makes the valgrind errors show up
<Akuli>
umm yes
<Akuli>
more like, deleting it fixes the stuff
<andrewrk>
Akuli, do you know about --disable-valgrind?
<Akuli>
no
<andrewrk>
that turns off the thing where zig teaches valgrind what `foo = undefined;` means
<Akuli>
errors seem to be coming anyway
<andrewrk>
right. so that points to a bug in valgrind rather than zig
<Akuli>
i first noticed this when a random number generator generated the same random numbers every time
<Akuli>
when not running under valgrind
<Akuli>
then i valgrinded it and it was reading uninitialized memory
<Akuli>
maybe i was doing something else wrong then
<daurnimator>
I was going to call it `nocopy` instead of `fixed` :P
<Flaminator>
IMO `fixed` and `nocopy` mean 2 different things.
<andrewrk>
Flaminator, explain?
<daurnimator>
Flaminator: which one means "this member is not allowed to be copied"
<Flaminator>
That would be nocopy daurnimator. For me fixed would mean it's stuck and you can't move it around but you can make a copy of it, while nocopy means you can move it around you just can't make an extra copy of it.
<daurnimator>
Flaminator: what does 'move it around' mean?
<daurnimator>
in a computer; moving *is* copying...
<Flaminator>
Bad analogy incoming: imagine a room, there is a box on the floor and a pilar that is stuck to the floor and the ceiling. You can move the box around from one position in the room to another while the pilar is fixed in that same position and can't be moved around.
<daurnimator>
Flaminator: I'm not sure what is the box/room/pillar in this analogy
<Flaminator>
The room is for example 200 bytes of memory and the box and the pillar are a byte each located in those 200 byes.
<daurnimator>
Flaminator: struct layout is static in zig: members don't move around the struct.
<daurnimator>
(it's undefined *where* they are; but they don't move once a location is picked)
<andrewrk>
if you copy bytes, then treat the newly copied bytes (which are in a different location) as a valid object, then according to the perspective of that object, it has moved
<andrewrk>
if you put me in a cloning chamber, and then when the clone of me walks out of the other cloning chamber, he's going to think he teleported
<Flaminator>
I don't really know what the nocopy/fixed thing is for though, was only saying that the words have a different meaning too me.
<diltsman>
It appears that build results are now in zig-cache/o/<CRAZY STUFFS!>/
commander has quit [Remote host closed the connection]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andrewrk>
diltsman, is it working ok for you? you can override it
<diltsman>
New behavior. Just was unexpected.
<andrewrk>
if you try your `zig build` commands a few times in a row you should see that everything is cached
<diltsman>
Right.
<andrewrk>
and try making a change in any file - .zig, .h, or use a different version of zig, anything! - and only what needs to get rebuilt will