<daurnimator>
andrewrk: 1. is layout of a `slice` defined? 2. can it be? (perhaps user controlled?) => why? a slice of slices should be a valid `const struct iovec *iov`
frett27_ has quit [Ping timeout: 260 seconds]
<mikdusan>
what I'd like to see are 2-sided (made up that name) page tables for virtual address space; one side is for stack, and other side is everything else. so thread can have it's own private stack, and thread-locals basically become globals. how much heavier does that make a thread? hopefully not much.
<mikdusan>
whups
reductum has joined #zig
<daurnimator>
mikdusan: the whole point of a "thread" instead of a process is that it shares all memory with other threads in the same process
<mikdusan>
that's not true
<daurnimator>
go on...
<mikdusan>
a thread needs private stack
<daurnimator>
its not private; just separate
<mikdusan>
can you give me a use-case where one thread accesses another's stack?
<daurnimator>
you can do `heysomeotherthread(&stack_variable)`
<daurnimator>
think of e.g. when you're using thread pools for IO
<mikdusan>
which callstack are those threadpools using?
euantor has quit [Ping timeout: 272 seconds]
ifreund has quit [Ping timeout: 250 seconds]
waleee-cl has quit [Read error: Connection reset by peer]
tributarian has quit [Ping timeout: 240 seconds]
euantor has joined #zig
<mikdusan>
i'd rather have a model where stack is thread-private and then have an alternate stack from process memory to do that kind of sharing
waleee-cl has joined #zig
tributarian has joined #zig
euantor has quit [Ping timeout: 260 seconds]
euantor has joined #zig
ForLoveOfCats has quit [Quit: Konversation terminated!]
<daurnimator>
:( looks like andrew broke preadvAll
<andrewrk>
I think the void return type just needs to be replaced with usize
frmdstryr has quit [Remote host closed the connection]
<daurnimator>
andrewrk: the arg needs to be not const
<daurnimator>
the doc-comment explains why :)
joey152 has quit [Remote host closed the connection]
<andrewrk>
ah nice catch
marijnfs1 has joined #zig
<andrewrk>
would be nice to have some test coverage for that fn
marijnfs has quit [Ping timeout: 260 seconds]
nephele has joined #zig
nephele_ has quit [Ping timeout: 265 seconds]
<daurnimator>
andrewrk: where is your sparc discussion happening?
<junon>
Just submitted a fix for #4909; PR is #4932
<junon>
Wasn't sure what to do with all of the private functions that needed fixing so any guidance would be appreciated. Plus, never touched stage1 before so I might be violating some House Rules w.r.t. the c++.
<junon>
There are a lot of places affected by this bug :/
mahmudov has quit [Remote host closed the connection]
_Vi has quit [Ping timeout: 272 seconds]
<andrewrk>
btw Cadey where did you land on getting zig code running on TempleOS? I'm typing up release notes and saw some of your contributions to the bring-your-own-os-layer
reductum has quit [Quit: WeeChat 2.8]
marijnfs_ has quit [Quit: Lost terminal]
ur5us has joined #zig
<Cadey>
i haven't really had any fruit yet, mostly been figuring out how to square peg / round hole it
<Cadey>
the file I/O stuff (and/or stdout printing) is a conceptually hard thing given there's no linker :D
<andrewrk>
interesting
ur5us has quit [Remote host closed the connection]
<andrewrk>
anyway just wanted to make note of that if you ended up getting it to some kind of milestone :)
<Cadey>
the weird part is that function pointers are limited to the lower 31 bits of a 32 bit address space, but pointers are 64 bits wide otherwise
<Cadey>
(basically it uses the `CALL` instruction instead of whatever way you are supposed to do it in amd64 on linux)
ur5us has joined #zig
<Cadey>
i mean, in theory it should work
<Cadey>
i'm just still figuring out what breed of goat i need to sacrifice and how to procure them given most stores are closed
<andrewrk>
here's what I've got so far on the release notes, and I'm only halfway through the commit logs: https://i.imgur.com/qyyYTRL.png
<Cadey>
honestly the bring your own OS layer is just _so good_
<Cadey>
it makes zig into a swiss army knife
<pixelherodev>
... I just realized that you have to write the release notes by hand every release
* pixelherodev
winces
<pixelherodev>
That does not sound fun
<shakesoda>
aw, i can't link my stuff against the prebuilt openxr sdk libraries
<shakesoda>
this is both completely expected and modestly annoying
<mikdusan>
one of my favourite 0.6.0 lang surprises is pointer-to-array; elegant and complements slice semantics very well
<andrewrk>
Thalheim is offering SPARC hardware for testing, if anyone wants to try their hand at #4931
<andrewrk>
you know what's funny though, is we often use `zig translate-c` with musl libc header files to figure out the OS bits
<andrewrk>
qemu also supports sparc64
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
oops, I meant to add: it's funny because Thalheim is the one working on musl support for sparc, and it's not done yet, so we wouldn't be able to do that yet
nycex has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 260 seconds]
nycex has joined #zig
<Thalheim>
andrewrk: if all you need is header bits most of those are done so far
<Thalheim>
which do you need?
<Thalheim>
mikdusan: it is 8t per core, 2 x 16-core cpus
<daurnimator>
oh doh; andrew already sent that link
junon has quit [Ping timeout: 252 seconds]
<Yardanico>
so is https://github.com/andersfr/zig-lsp abandoned now? it was a pretty useful thing so you could get error highlighting in editors which support LSP
<pmwhite>
on that same note, I think I've seen andrew get some error reporting during his coding streams. anybody know where that comes from? It doesn't seem to be built into the vim plugin.
<mikdusan>
yes that is the vim plugin using `zig fmt` in vim's path environment
<mikdusan>
every write/save in vim runs `zig fmt` on the buffer
<pmwhite>
I'm using that plugin, but I don't get an error window when there is a syntax error...it just fails to format.
<mikdusan>
in the shell that launched vim do `which zig`
<mikdusan>
ie zig must be in path env before launching vim
<shakesoda>
"std.os.getenv is unavailable for Windows because environment string is in WTF-16 format. [...]"
<shakesoda>
hahahaha, oh man
<shakesoda>
whoever wrote that error message, thanks
<mikdusan>
git blame says andrew
<shakesoda>
keep it forever
Kingsqueee has joined #zig
* pixelherodev
laughs audibly, which is bad because it's 2 am and people are sleeping
<pmwhite>
mikdusan: zig is on my path. I mean, the plugin does autoformat code on save. it just doesn't bring up an error window when syntax is invalid. If zig weren't on my path, then I would expect the autoformat to not work.
<mikdusan>
oh i guess some other vim setting is preventing that
<pmwhite>
Thanks...I was just looking at the vim plugin and trying to debug it. It looks like it is indeed getting to the line where it tries to execute "lopen"
<pmwhite>
so, no solution yet, but progress.
marmotini_ has joined #zig
<pmwhite>
mikdusan: what version of vim are you using? I'm using vim 8.
<pmwhite>
Ah, I got it. I had the line `let g:syntastic_always_populate_loc_list = 1`
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
frett27 has joined #zig
marmotini_ has quit [Ping timeout: 260 seconds]
reductum has quit [Quit: WeeChat 2.8]
slowtyper has quit [Quit: WeeChat 2.7.1]
slowtyper has joined #zig
junon has joined #zig
mahmudov has joined #zig
ur5us has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 265 seconds]
frett27_ has joined #zig
frett27 has quit [Ping timeout: 264 seconds]
TheLemonMan has joined #zig
frett27 has joined #zig
Patrice_ has joined #zig
<Snektron>
I wonder if its useful to give allocators a 'preferred allocation granularity'
frett27_ has quit [Ping timeout: 260 seconds]
<Snektron>
For example, a page allocator only allocates in blocks of mem.page_size
<Snektron>
So in arena allocator, blocks are allocated in that size, regardless of the backing allocator
KoljaKube has joined #zig
frett27 has quit [Ping timeout: 260 seconds]
<KoljaKube>
Hello
<Snektron>
Hi
WilhelmVonWeiner has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
frett27 has joined #zig
marijnfs has joined #zig
ifreund has joined #zig
Patrice_ has quit [Ping timeout: 265 seconds]
daex_ has quit [Ping timeout: 260 seconds]
KoljaKube has quit [Ping timeout: 272 seconds]
Kingsqueee has quit [Quit: Konversation terminated!]
daex has joined #zig
<ifreund>
would anyone happen to have a good example of a simple, non-library project with tests set up?
<ifreund>
I tried to just import my project with addPackagePath but everything is private it seems
daex has quit [Ping timeout: 240 seconds]
<marijnfs>
just make things pub?
<marijnfs>
stuff thats not pub is not exposed
<ifreund>
i guess the other option would to split my project into a lib add executable, then run tests on the lib
<ifreund>
s/add/and/
<ifreund>
it is pub though
<marijnfs>
hmm
<ifreund>
maybe I've just set things up strangely
<marijnfs>
are the tests defined in the code itself?
KoljaKube has joined #zig
<ifreund>
no i made a separate test folder
<ifreund>
I can push a dysfunctional branch if you like
<marijnfs>
sure maybe i can see something
<marijnfs>
not a zig expert but have been picking it up
<magejohn>
also, what's the best translation of make 'targets' to a zig build system? i.e, how do I get things like 'zig build all', 'zig build release', 'zig build docs', etc? does each call to builder methods like Builder.addExecutable add one or something?
<ikskuh>
you can create named steps
<ikskuh>
with dependencies
<ifreund>
i believe `zig init-exe` gives you a run step for example
<magejohn>
cool, i didn't even realise zig had the init-exe and init-lib options, actually. i'll take a look at what it generates as a reference then
<magejohn>
the zig build system could really use docs :joyful: maybe once i've made this one i'll know enough to start writing them
<magejohn>
* the zig build system could really use docs 😂 maybe once i've made this one i'll know enough to start writing them
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
marmotini_ has joined #zig
josch557 has quit [Ping timeout: 260 seconds]
<ikskuh>
yeah, true
<ikskuh>
can someone explain what usecase `std.atomic.Queue(T).dumpToStream` has`
<ikskuh>
it looks like it dumps both head and tail and up to 4 following items
<KoljaKube>
Maybe debugging?
<ikskuh>
yeah
<ikskuh>
but i wonder what the implementation does
<ikskuh>
it tries to print up to 4 elements from the tail
<ikskuh>
where to my understand the tail has always ".next == null"
<KoljaKube>
Good point
<KoljaKube>
Might be an oversight. The Node is doubly linked as far as I can see, would just need to read `prev` instead of `next` for the tail
<ikskuh>
+1 pull request
scientes has joined #zig
livcd has quit [Ping timeout: 272 seconds]
<KoljaKube>
How can I allow field access for my struct?
<ikskuh>
right now it's just there
<ikskuh>
all struct fields are public
<ifreund>
maybe you have a ?* pointer to the struct?
<KoljaKube>
Oof, yes, sorry
<KoljaKube>
I forgot that this variant of the function returned a !Size
frmdstryr has joined #zig
<ikskuh>
daurnimator: thanks for tagging :)
<TheLemonMan>
mps, check out 839d85e4405aef4856d1a35a6580226e997cc369
<andrewrk>
mps, I think your issue will be solved if you update zig sources to latest master branch
<mps>
aha, I thought that this could be solution. thanks. will try with current master
<andrewrk>
TheLemonMan, did you see my comment on #4737?
<TheLemonMan>
yeah I'll check it out later, got sidetracked learning about sparc
<andrewrk>
I had a feeling that would "spark" your interest
<Thalheim>
TheLemonMan: that's the kind of enthusiasm I love to hear
<andrewrk>
Thalheim, if you didn't see above: <TheLemonMan> ok so I got a quick and dirty sparcv6-linux port going...but it seems LLD doesn't support the elf64_sparc emulation mode!
<Thalheim>
sparcv6 should not be used; v7/v8 is "32-bit sparc" and v9 is "64-bit sparc"
<Thalheim>
so elf64 makes no sense
<TheLemonMan>
well by 6 I meant 9
<andrewrk>
so part of this task would be sending a patch upstream to LLD (or just convincing one of the devs to do it) and then either re-forking LLD or waiting until 11 comes out
KoljaKube has quit [Ping timeout: 265 seconds]
<andrewrk>
we could also consider carrying LLD/LLVM patches in the bootstrap repo (as long as they are merged upstream)
<andrewrk>
Thalheim, TheLemonMan is a well-respected member around here, certainly someone you would benefit from giving access to sparc hardware
<Thalheim>
TheLemonMan: on the understanding that it's not online 24/7, but can be "turned on upon request" (just ping me or email me), happy to accommodate.
<Thalheim>
pm me your pubkey
<TheLemonMan>
thanks for the kind words heh Thalheim, I'd wait 'till I have at least something working and running on qemu
<Thalheim>
depends on how much you value your time. it's no inconvenience on my end.
<fengb>
Old school lambda function: using a person 🤔
<magejohn>
is there an easy way to have a build.zig make a directory if it doesn't exist yet?
<magejohn>
hold on, i wasn't reading the error message properly, it looks like it's trying to do that already.
<TheLemonMan>
yeah that's unfortunate, v6 has no yield
<TheLemonMan>
we should gate that with some feature check
<mps>
TheLemonMan: I'm building it on alpine armv7 arch
ifreund has quit [Quit: WeeChat 2.7.1]
<TheLemonMan>
are you explicitly setting the cpu?
ifreund has joined #zig
<TheLemonMan>
zig defaulted to the thumb-only v6m architecture 'till some weeks ago
ifreund has quit [Client Quit]
<mps>
no, I use default for alpine armv7
ifreund has joined #zig
<mps>
and, thumb is default in gcc on armv7 (again on alpine)
<TheLemonMan>
re-read my last message, the default was --> _v6m_ <--
<mps>
hmm, maybe I should upgrade to gcc 9.3.0
<mps>
ah, I see
<TheLemonMan>
check out 2b33e27e1
<mps>
TheLemonMan: ok, will do (after coffee break)
<TheLemonMan>
nonetheless we should add a feature check in the spinlock implementation
ifreund has quit [Quit: WeeChat 2.8]
<andrewrk>
mps, the build that worked successfully for me was: -target arm-linux-musleabi -mcpu=generic+v6kz
<Thalheim>
andrewrk: all right, now that I've got coffee in me I'll see what I can do about getting you those bits.
<Thalheim>
unless "quick and dirty port" means I'd be duplicating effort, in which case I'll poke at musl
<andrewrk>
if I understand correctly, the bottleneck is now known to be LLD, so you may as well work on musl
<mps>
andrewrk: undestand, but I want to use default flags as much as possible for distro package
<andrewrk>
oh it's arm v7? in this case I think you want: arm-linux-musleabihf (no -mcpu parameter needed; it defaults to v7a)
<andrewrk>
you need the latest zig sources - as TheLemonMan noted we have been working on this very recently
<andrewrk>
the arm v7a build also worked successfully for me
<mps>
will be in about one hour again on the armv7 machine and will post you default gcc flags on alpine
* ikskuh
is porting a portion of C++ code to zig and it's a really good feeling to finally attack all those tiny little buggers where exceptions were not handled correctly
<ikskuh>
++stability
frmdstryr has quit [Ping timeout: 256 seconds]
<magejohn>
so, i'm getting an error when i set the output dir of something in my build.zig and the output dir doesn't exist yet. the error returned is FileNotFound, which makes sense, but the error trace starts with a error.PathAlreadyExists, which is confusing me. the way I understand the trace, it's trying to make the missing directory, hitting an error.PathAlreadyExists (which it doesn't), and then turning that into an
<andrewrk>
error return traces show "caught" errors too. There is a plan to improve this, but for now you'll have to do a little sleuithing to understand what happened
<magejohn>
cool, thanks. I'll have closer look at the library code then
<fengb>
This looks familiar. It was also a confusing resolution for me last time
<TheLemonMan>
ok I've hacked zig to use sparc64-linux-gnu-ld and now I have working binaries
<ikskuh>
\o/ ?
<TheLemonMan>
sometimes you gotta do what you gotta do
<ikskuh>
how many platforms does bootstrap now support? :D
<andrewrk>
still haven't got it to build for windows yet
<ikskuh>
:D
<ikskuh>
nah, who needs windows anyways :D
<andrewrk>
for some reason it thinks defined(CYGWIN)
<ikskuh>
but i can imagine that windows is actually harder than other-cpu linux distros
<ikskuh>
because linux has at least the same APIs
<magejohn>
looks like the PathAlreadExists part is to do with the zig-cache. +1 for zig building it's std lib from source, btw. I just threw a std.debug.warn in the relevant function in the std lib, and it got used. hacky, but much faster than trying to follow the chain of function calls down
<ikskuh>
yep
<andrewrk>
yeah, "no installation steps" is a big feature
ifreund has joined #zig
<magejohn>
okay, so then my question from earlier is still relavent. is there an easy way to get the zig build system to make my output dir for me? or should I just call std.fs.cwd().makeDir()?
<ikskuh>
create a step that does this :)
dddddd has joined #zig
<magejohn>
that sounds right
<magejohn>
thanks :)
<andrewrk>
magejohn, this is the directory that you're using with setOutputDir() ?
<magejohn>
yeah, that's right
<andrewrk>
I think that might be a good idea to change, but first can I ask, why not use the more idiomatic setup, with no output dirs?
<andrewrk>
the default build step is "install" and the default install directory is "zig-cache"
<andrewrk>
so your stuff will end up in zig-cache/bin/foo or zig-cache/lib/bar
<andrewrk>
you can also change the default install directory in the build script
slowtype1 has joined #zig
<magejohn>
the reason is i'm trying to recreate a make based build system
<magejohn>
but that sounds like an easier way, actually
<magejohn>
not certain what the value is in holding too closely to the existing structure
slowtyper has quit [Ping timeout: 260 seconds]
<magejohn>
just tried it that way, works great
<ikskuh>
andrewrk: is it okay to have a function "export fn foo(x: *i32) callconv(.C) void" exported to C?
<magejohn>
i was wary of the default install step, because i thought it might try to install into a system directory like many build systems do
<ikskuh>
it's undefined behaviour to call this with a nullptr, but: is this checked in debug builds?
cole-h has joined #zig
<andrewrk>
magejohn, in my opinion the "default" should generally be targeted at project contributors, and package maintainers can pass the "OK I'm packaging this software now" configuration options
<magejohn>
andrewrk: that's a great default, i like it. just not what i'm used to 😂
<andrewrk>
ikskuh, yes it's OK to do that, and yes it will be UB if the C function calls it with nullptr, and I don't think we have a safety check for it. I vaguely recall a related issue
<ikskuh>
okay :)
<ikskuh>
would be a pain to have C pointers everywhere in the API
<ikskuh>
if i know better what kind of pointer that is
<andrewrk>
I agree that if the C function is not supposed to pass null, then *T is appropriate
<ikskuh>
much better documented then as well
<andrewrk>
I think we should safety check it, because we do have the ability to disable the safety for any functions that are "hot"
<ikskuh>
yeah, true :)
<andrewrk>
once gen-h gets resurrected, it will be able to place a nonnull attribute as well, and maybe even c compilers can catch mistakes
<ikskuh>
yeah that was my thought exactly :D
<ikskuh>
it could even generate a comment like "foo(/*many*/ int * items)"
<andrewrk>
I was thinking we could propose a backwards compatible extension to C header files which allows annotating types with more information
<andrewrk>
upstream projects could opt in to these extra annotations, and it would make translate-c work better (not just for zig but for all projects that want to generate bindings)
<ikskuh>
something like "just a bunch of empty macros"?
<ikskuh>
#define PTR_TO_MANY *
<ikskuh>
int PTR_TO_MANY array;
<andrewrk>
that's probably not sufficient, but yes something like that
<ikskuh>
that's definitly a would-be-cool-thing, but i think zig has other problems right now :D
<bsrd>
nvm: // /usr/include/wayland-util.h:636:2: warning: TODO implement translation of DeclStmt kind Record
KoljaKube has joined #zig
<andrewrk>
r4pr0n, I have tests running for openpty (adding libutil support to zig's glibc). For the other thing, I filed this issue: https://github.com/ziglang/zig/issues/4938
<r4pr0n>
ah nice, thanks
mahmudov has quit [Ping timeout: 265 seconds]
<andrewrk>
also that issue is easy, going to knock it out real quick
<r4pr0n>
btw, i didn't find this on the issue tracker, but is it known that when you translate-c a c file with a int main() but doesn't actually have a return statement (valid in c) doesn't work when translated to c?
<TheLemonMan>
andrewrk, can you remind me how to check if the current target has a given feature?
<andrewrk>
in any context where the type is expected to be an enum this works
josch557 has quit [Remote host closed the connection]
<ikskuh>
hm
<ikskuh>
translate-c is not made for translating a full C library D
<springworm>
would i have to be in the same namespace? c.SND_PCM... is the const
<springworm>
ikskuh: i'm not trying to translate ALSA, i just want to build/link against it
<ikskuh>
yeah
<ikskuh>
but me :D
<ikskuh>
well, not alsa but picohash
<ikskuh>
let's just say: in zig, a function pointer is const whereas in C it's not
<ikskuh>
:D
<springworm>
i sure hope picohash's fn pointers aren't mutating...
<ikskuh>
nah
<ikskuh>
it's a bug in translate-c
<pixelherodev>
ikskuh, ;)
* ikskuh
is scared though :D
<pixelherodev>
The one mitigation I set though was to use Git hooks to limit how many it will allow
<ikskuh>
only the huge functions are left
frmdstryr has joined #zig
springworm has quit [Ping timeout: 260 seconds]
frett27_ has quit [Ping timeout: 256 seconds]
springworm has joined #zig
josch557 has joined #zig
FireFox317 has joined #zig
<andrewrk>
r4pr0n, the new tarballs are up with those fixes
<Snektron>
andrewrk, what do you think about giving allocators some way to communicate a preferred allocation size?
<Snektron>
As for example arenaallocator allocates in mem.page_size granularity, while that might not always be optimal
<andrewrk>
you can always communicate such things out-of-band
<andrewrk>
the Allocator interface is intentionally abstract, and hides such details
<andrewrk>
maybe you don't want to go through this interface in this case?
<Snektron>
I don't have any immediate needs
<Snektron>
It just seemed logical
<r4pr0n>
andrewrk: well it kind of works now... i don't get that error anymore, but i get the following, may that have something to do with the libutil fix?
<r4pr0n>
well that paste has gotten a god random name
<r4pr0n>
good*
<andrewrk>
ha
<FireFox317>
xd
<andrewrk>
ok my working hypothesis of what's happening here is glibc 2.17 has no symbols inside libutil (which would mean the `openpty` link error is correct), and zig is not handling generating an empty .so file correcctly
<r4pr0n>
so the earlier error would be correct?
<andrewrk>
hmm that does not appear to be correct - looks like that function was added in GLIBC_2.2.5
ifreund has quit [Ping timeout: 265 seconds]
<andrewrk>
r4pr0n, can you double check that you replaced all the lib/ files with the new tarball rather than only the binary?
<andrewrk>
maybe for my sanity, sha256sum lib/libc/glibc/abi.txt
<r4pr0n>
oh
<r4pr0n>
that may be the problem, i thought it wouldn't be because it was statically linked
<r4pr0n>
where to i have to put all those? /lib? (normal linux fs structure)
<andrewrk>
zig finds its lib directory by searching relative to the binary. so you can do a standard posix file system install, or you can simply untar and run from there
<andrewrk>
but the binary does depend on being paired up with exactly the lib/ files that it ships with
<andrewrk>
well not necessarily exactly, but you get the idea. if you update zig you have to update the lib/ files too
<r4pr0n>
when the ran executable from $PATH is a symlink, do i have to put it to the symlink or to where the symlink is pointing to?
<r4pr0n>
seems to work when i put it at the destination of the symlink
<andrewrk>
it will look for the lib files relative to where the symlink is pointing to
<r4pr0n>
well it works now andrewrk, so the issue is fixed
<andrewrk>
great. glad I didn't try to debug that, ha
<r4pr0n>
yeah xd
<r4pr0n>
sorry for wasting your time there
<andrewrk>
no worries, it was equally likely to be my fault :)
<andrewrk>
watcha doing btw?
<andrewrk>
just curious, it's always interesting when someone is linking xll
josch557 has quit [Quit: ERC (IRC client for Emacs 26.3)]
<r4pr0n>
oh it's actually not my c code, i just wanted to try building the terminal i use with zig
<r4pr0n>
well it was the same error for my window manager, which now also works flawlessly with zig cc :D
ur5us has joined #zig
KoljaKube has quit [Ping timeout: 265 seconds]
<r4pr0n>
though my terminal crashes due to illegal instruction while my window manager doesn't, i'm gonna try to isolate the problem
<andrewrk>
r4pr0n, ah, you should know that zig enables UBSAN (undefined behavior sanitizer) if you do not disable it or add optimization flags
<andrewrk>
if your c flags contain -O2 or -O3 that would disable it by default, or you can explicitly add -fno-sanitize=undefined
<andrewrk>
or you can find the bugs and submit fixes upstream :)
<andrewrk>
"UndefinedBehaviorSanitizer is not expected to produce false positives. If you see one, look again; most likely it is a true positive!"
<r4pr0n>
yeah, disabling the sanitizer "fixes" it
<r4pr0n>
i'll audit the code and look for the ub
<andrewrk>
if you build with debug symbols, gdb should point you to exactly the line of problematic C code
<r4pr0n>
is there any information why it thinks it's undefined behaviour?
<r4pr0n>
and the weird thing is, this illegal instruction error only occurs, when i apply a patch to the terminal to add alpha support to the colors, but the part which gdb gives me is somewhere which is being edited by that patch so i don't really know what's wrong
<andrewrk>
(this requires more libraries to be installed which is why zig does not offer this)
<r4pr0n>
oh, that helped, i found the part, zig cc now also builds it successfully ✅
FireFox317 has quit [Ping timeout: 240 seconds]
<r4pr0n>
for what it's worth, zig actually showed the wrong line number, but clang showed the correct one
<r4pr0n>
but i guess that's also because of those additional libraries
r4pr0n has quit [Quit: r4pr0n]
springworm has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 260 seconds]
springworm has joined #zig
<andrewrk>
hmm that's interesting. what do you mean zig showed the wrong line number? you mean in gdb the backtrace?
<andrewrk>
or did you somehow integrate zig's debug info / stack traces?
r4pr0n has joined #zig
r4pr0n has quit [Client Quit]
r4pr0n has joined #zig
<r4pr0n>
er no, i mean the line number in gdb, when compiled with -ggdb
<r4pr0n>
or rather yes, in the backtrace of gdb
<r4pr0n>
well it was in the same function but a few lines off
<r4pr0n>
and the c code gdb showed was the one that was on the line gdb showed, not the problematic code
<andrewrk>
interesting
<andrewrk>
well if that's to be improved that would be in clang's codebase
<r4pr0n>
even though clang shows the correct one?
<andrewrk>
it's clang either way
<andrewrk>
they've clearly been prioritizing the use case where those libraries are compiled in, and not the use case of making the debug info accurate on the trap instruction
<andrewrk>
which is understandable - but this other use case is also valid
<r4pr0n>
well i guess i'll report that then, i'm just creating a minimal example
<r4pr0n>
is it possible to use clang but not use those libraries?