<Snektron>
you can see that it sets _DCMAKE_PREFIX_PATH
<swoogan>
sorry, Ubuntu 18.04 64bit
darithorn has joined #zig
schme245 has quit [Remote host closed the connection]
<hryx>
swoogan: the cmake flag Snektron mentioned will allow you to specify the path to your custom build: `cmake .. -DCMAKE_PREFIX_PATH=/path/to/llvm`
<hryx>
but it's also possible to use LLVM installed via apt if you follow the instructions at https://apt.llvm.org/ (although I think that page is hard to understand properly)
<hryx>
look under Ubuntu, under Bionic (18.04). Those lines are what you need to add to /etc/apt/sources.list.d/additional-repositories.list (or another file in that directory). Then `sudo apt update` and install the relevant clang/llvm packages
<hryx>
Exactly which packages you need, I forget. That LLVM page also lists which ones are available
<swoogan>
DCMAKE_PREFIX_PATH worked. I got confused and thought that told cmake where to install zig
<swoogan>
thank you
ur5us has quit [Ping timeout: 260 seconds]
euandreh has quit [Ping timeout: 252 seconds]
ur5us has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 265 seconds]
_whitelogger has joined #zig
Snetry has quit [Quit: left Freenode]
mahmudov has quit [Remote host closed the connection]
<WendigoJaeger>
Is there any plan to support align(x) for const variable and/or @embedFile, I would need those const array to be "allocated" in .rodata at aligned address.
<hryx>
Hey daurnimator I'm super confused about something that you maybe can help me understand. I just made a fix for https://github.com/ziglang/zig/issues/2379 but now looking closer, the last test case "\uDEAD" is considered invalid because it falls in the range D800-DFFF ("UTF-16 surrogate pairs"). So should that string be allowed or not?
<daurnimator>
hryx: yes its invalid unicode. no it probably shouldn't fail.
<daurnimator>
hryx: json strings are allowed to not be valid unicode :P
<hryx>
From what I understand about the WTF-8 discussions, the issue is about working around invalid utf-16 in windows paths. But I'm not sure I understand why this affects JSON since the RFC specifically says it has to be valid utf-8
<daurnimator>
Automatic decoding/encoding of a zig type to/from json
<hryx>
I love it
<daurnimator>
It has a few TODOs left (was running into compiler bugs/crashes); then will reopen the PR (it is/was #3155)
leeward has quit [Quit: *Poof*]
<hryx>
wow, that section you linked straight up says that `\uDEAD` is legal in this newer JSON spec. oy
<hryx>
I misread, it does not say that it's allowed (reading is hard)
ur5us has joined #zig
<daurnimator>
hryx: yes it does... "the ABNF in this specification allows ...."
<hryx>
So when it follows that with "implementations might return different values for the length of a string value or even suffer fatal runtime exceptions", are they just saying "use those characters at your own risk"?
<daurnimator>
hryx: yep.
<daurnimator>
15:47:15 <daurnimator>json implementations are generally quite non-conformant
<hryx>
good enough for me!
ur5us has quit [Ping timeout: 260 seconds]
<hryx>
Ahhhh, it also says this: "JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629]." That's probably what got me reading the other spec and questioning this whole thing.
<hryx>
so like you said daurnimator this should be a decode option
<daurnimator>
hryx: yep. in my auto-json branch there's the start of a decode-options struct.
<daurnimator>
should get added in there
ltriant has quit [Quit: leaving]
dddddd has quit [Ping timeout: 268 seconds]
SimonNa has quit [Remote host closed the connection]
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
WendigoJaeger has quit [Quit: Connection closed for inactivity]
schme245 has joined #zig
schme245 has quit [Remote host closed the connection]
<mq32>
> It doesn't fix use-after-free, double free().
<mq32>
because no programming language can fix programmers :D
<fengb>
I'm pretty sure Rust has mechanisms fix those
<mq32>
afaik only with a "runtime linter"
dimenus has joined #zig
<fengb>
But the ownership checker should mark variables as freed and thus you can't use them any more
<dimenus>
is it possible to have a func with a comptime parameter call another func with a comptime parameter? (all other params in both funcs are runtime known)
<dimenus>
i'm getting 'unable to evaluate constant expression' but it's kind of hard to troubleshoot
<mq32>
dimenus: you need a comptime parameter for that
<mq32>
but can you show code?
<dimenus>
i'm using a comptime parameter, it's a bunch of code but i'll try
henbr has quit [Quit: WeeChat 2.6]
<fengb>
I've ran into that a few times as well
<fengb>
My understanding is that one of the parameters aren't properly comptime but that's only a guess
<dimenus>
It all works fine until I added a 'base_type' field to the Buffer struct
<dimenus>
now it won't evaluate
<dimenus>
hmmm, maybe my assumption is just wrong. The space occupied by type could be different depending on the type no?
<mq32>
dimenus: you are not allowed to store types in runtime values
<dimenus>
duh. my bad. i'll just store the typeid
<dimenus>
all i'm doing is a bit of runtime type checking (knowing that compile time type checking is preferred)
schme245 has joined #zig
Akuli has joined #zig
schme245 has quit [Remote host closed the connection]
Snetry has quit [Ping timeout: 265 seconds]
mahmudov has joined #zig
THFKA4 has joined #zig
FireFox317 has joined #zig
<FireFox317>
andrewrk: for the run-translated-c tests is it an idea to always concatenate in front of the test cases an static function `test_assert` which does `if (!ok) abort()`. In that way people that write run-translated-c test code, they can use this function instead of writing `if (x.a != 3) abort()` everywhere. I think this will work when #4083 is merged.
<FireFox317>
I think the asserting is anyway a better approach then comparing the stdout
<via>
i was considering just including assert.h and using asserts
<via>
which just calls abort
<via>
was planning to update #1158 to do that tonight
<via>
er, #4085*
<FireFox317>
well, the current code cannot translate assert.h correctly yet, and i think `assert` in assert.h also does other stuff like printing a stack trace or something
<via>
i think abort() just does that
<via>
but damn, nevermind then
ky0ko has joined #zig
<FireFox317>
that's why i thought just add this function and use that in all the cases. But assert.h is also an option indeed
<via>
actually it looks like it does fail to translate assert macro, but it still translates to correct asserting code
TheLemonMan has joined #zig
henbr has joined #zig
<TheLemonMan>
yeah, your best bet atm is to use abort()
<TheLemonMan>
there's a WIP allocator that aims to catch most of those problems
<azth>
Most, or all? :)
<mq32>
"most"
<azth>
From (https://github.com/ziglang/zig/issues/2402): "In safe build modes, runtime safety checks attempt to detect illegal behavior, but not all kinds of illegal behavior can be detected."
<azth>
What can't it detect then?
<mq32>
"use after free" cannot be detected on platforms that don't have MMUs with certain features
<fengb>
It's execution based
<azth>
Do you mean runtime caught?
<fengb>
Yeah
<mq32>
zig (as a language) does not now about a "heap", so there is no concept of "use after free" in the language itself, but it's a userland concept
<azth>
That's a fair way to go about it. The question is, what can't be detected at runtime at the moment? mq32 mentions one example.
<azth>
It's a tradeoff as. Rust trades write time complexity to statically prove that use-after-free doesn't happen.
<mq32>
azth: depends on the platform, but "invalid memory access" in general cannot be detected
<azth>
If it's caught at runtime though, it can be a worth while trade to writing simpler code.
<fengb>
mq32: we can detect writing to "undefined" for debug builds. And we can manually set all free memory to undefined
<mq32>
azth, yeah but using rust for freestanding removes all this safety
<mq32>
fengb: nice to know!
<fengb>
azth: I definitely agree here. I just want to make sure we all understand that Zig's direction isn't theoretically "sound" :P
<azth>
mq32, what do you mean by "freestanding"?
swoogan has quit [Remote host closed the connection]
<mq32>
using no OS
<mq32>
so: no system-provided allocator
<fengb>
Especially since this would most likely only exist in debug builds. I guess we can see how efficient it could be to include these features in release-safe
<azth>
I see
<mq32>
which means you don't have a concept of "malloc" anymore
<mq32>
or more correct: you have to implement malloc in userspace
<azth>
mq32, by "invalid memory access", do you mean things other than out-of-bounds reads/writes?
<azth>
perhaps writing on the stack
<azth>
return address buffer overflow?
<mq32>
i mean "reading/writing any memory that has not been meant to be accessed"
<mq32>
like non-existing memory for example
<fengb>
We might need a 2nd concept of undefined here. "Mapped but not used" vs "unmapped"
<azth>
mq32, fair enough, and in this case you're referring to Zig specifically, not Rust for instance, correct?
<mq32>
no, i refer to "executed code"
<mq32>
like "mov [eax], 10"
Akuli has quit [Quit: Leaving]
<mq32>
which will write 10 to the address stored in eax
<fengb>
How do cpus handle non-existent memory?
<mq32>
"it depends"™
<azth>
Right, so it's the language/runtime's job to mitigate or prevent that then.
<mq32>
Cortex-M3 will just do it
<mq32>
and then ... stuff happens :D
<mq32>
maybe nothing
doublex has quit [Ping timeout: 265 seconds]
<mq32>
AVR will happily just read/write to "nothing" and give you random values
<fengb>
Sounds like fun bugs :P
<mq32>
x86_64 will do what the processor is configured to do
<mq32>
so it may reset, just happily do what you told it, call an interrupt handler, invalidate caches and reload stuff, ... :D
<TheLemonMan>
halt & catch fire
<nofmal>
hello, is it possible to export a struct into c header file?
<nofmal>
really? but there was no compiler error tho?
<mq32>
azth, i can't find the right rust code right now, but "@intToPtr([*]u8, 0xB8000).* = 'A';" is sometimes totally legit code and sometimes it's not
<mq32>
and as long as your language does not know the difference between "heap pointers" and "non-heap pointers", you cannot really detect use-after-free or double-free
<mq32>
at least at compiletime
<TheLemonMan>
oh it seems that exporting some zig types is somehow supported... no idea what that's supposed to do tho
<TheLemonMan>
speaking of AVR, it should be relatively usable as a target now
SimonNa has joined #zig
<mq32>
TheLemonMan: nice! i wanted to try that this week agian
<TheLemonMan>
the stdlib support is quite spotty as `usize` is only 16 bit wide and some casts may be needed here and there
<nofmal>
TheLemonMan: i tried `export var` and it works. thank you so much
<mq32>
i still wonder how usize is defined exactly
<nofmal>
it kinda sucks that you have to make new variable and fill out all the fields tho
<mq32>
i would like to see some other "special" ints as well: uintptr and uregister
<fengb>
Actually no. Once I switched to this, everything else stopped complaining
<andrewrk>
interesting
<fengb>
Since nothing is fully recursive now, Zig is resolving it
<fengb>
I think that still needs to be addressed to shrink the necessary frame size, but it's more of an optimization
<andrewrk>
regarding the bloat - I think it's possible for the compiler to detect this situation and remove the bloat. there might already be an llvm pass that does this. I think it's something we can address in the compiler implementation details later
<andrewrk>
you can sort of get an idea of what is planned with regards to safety here
<andrewrk>
I'm guessing you're coming from the news article in which people are comparing zig and rust. I can give you the short summary there
<scientes>
*-fwhole-program
<andrewrk>
compared to rust, zig gives up compiler-guaranteed safety, in exchange for language simplicity. zig's safe release mode uses runtime checks, whereas rust's release mode is safe without any such runtime check cost
<andrewrk>
in return, zig programs are simpler to read and understand than rust programs
<andrewrk>
that's about it
<companion_cube>
(rust does have to keep some runtime checks for RefCell and for bound checking)
<andrewrk>
ah right
<azth>
andrewrk, yes I understand that, and it's a completely fair tradeoff. My question is however, would safe mode Zig be able to detect all memory errors (at runtime) that Rust prevents at compile time?
<scientes>
glibc is also full of runtime checks
<scientes>
even for std::mutex
<companion_cube>
i wonder, could pointers use pointer tagging (use the 2 LSB) to store a "generation" in them; the allocator also keeps a generation and these are matched upon `free`. 1 chance in 4 to be ok by chance in case of double free?
<mq32>
companion_cube, that sounds like it would have too much potential for accidently messing up stuff
<azth>
andrewrk things like double frees, iterator invalidation, etc. If not, would a list of such errors be made available, if that's possible to begin with?
<andrewrk>
azth, no certainly not all memory errors. however I do have a plan for most use-after-free and double-free bugs
<andrewrk>
btw, any person who enjoys wasm want to experiment with setting up a zig-in-the-browser sandbox where the programs are executed client-side?
<mahmudov>
btw just curious, zig master always tracks current llvm?
<andrewrk>
mahmudov, yes
<TheLemonMan>
speaking of llvm, where the hell is LLVM 9.0.1?
<andrewrk>
at least for now - and our releases are 1-3 weeks after llvm releases
<andrewrk>
heh yeah the final rc was weeks ago
<fengb>
andrewrk: I'd love to. Though last time when I tried it, I was hitting major emscripten bugs
<andrewrk>
ah
<andrewrk>
I think I saw that someone got it working for clang, which gave me hope
<mahmudov>
i am asking because so tracking zig also need to track llvm versions
<mahmudov>
will need*
<TheLemonMan>
oh it was released on the 20th of December, still no trace of it in the APT repo
<andrewrk>
fengb, it downloaded a lot of bytes, but I think in zig with some #ifdefs for emscripten we can lighten the load. for example we can disable the @cImport feature
<fengb>
I can try again now that I have a bit more experience
<FireFox317>
frmdstryr: you have to enable them. See clashOS or LIMNOS for example repo's.
<TheLemonMan>
FireFox317, declaring a local and returning it by value should do the trick
<andrewrk>
FireFox317, https://github.com/ziglang/zig/issues/2765 would make that guarantee to not copy, however in this case the copy is semantically not important (and will likely get optimized anyway)
<FireFox317>
Thanks guys! I will try to implement it
<andrewrk>
#2765 is more for when you need to make fields have pointers to other fields
<fengb>
I was trying to avoid the .? unwrap for the suspended frame since that "feels" gross
<mq32>
hm
<mq32>
will the frame change between suspend and consume?
<fengb>
And also, the "out" is still technically available. I just hide it "just cause you might misuse it"
<fengb>
Nope
<fengb>
So I'm not sure. The ML part of me is attacking the sys part of me >_>
<mq32>
it will be valid from "first start" until the generator switches to "complete", right?
ntgg has quit [Ping timeout: 258 seconds]
<fengb>
It "starts" in the complete state. I need to rename it
<fengb>
But I couldn't figure out what word to use "start / complete"
<mq32>
can you elaborate what the state exactly means?
<fengb>
pending = we've stored an item in the generator, consumed = the previous item was used, complete = generator hasn't been initialized or has been complete
<fengb>
The first really only exists because there's an internal weirdness that I can't resolve nicely :/
<mq32>
hm
<mq32>
you could rename "complete" to "inactive"
<fengb>
That sounds so much better lol
<fengb>
I could also do `if (out) |stored an item| else if (suspend) |resumable| else |complete|`
<fengb>
The state is slightly more implicit but there wouldn't be this weird juggle
<mq32>
hmm
darithorn has quit [Quit: Leaving]
<mq32>
but looks like you got generators working on top of async, right?
<fengb>
Yep
<fengb>
Trying to resolve this footgun and getting into a bunch of internal arguments on which is the best way :P
<mq32>
nice
marmotini_ has joined #zig
<FireFox317>
I made #4092 regarding std.mem.zeroes
<TheLemonMan>
FireFox317, I'd add a comptime check to make sure T is not zero-sized
decentpenguin has quit [Quit: decentpenguin]
<mq32>
FireFox317: i would use some comptime reflection to fill everything in the struct with zero
<mq32>
not for extern/packed types, but for zig-native ones
<mq32>
as they *may* store additional information
marmotini_ has quit [Ping timeout: 265 seconds]
<FireFox317>
Okay, will see what I can add
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
riba has joined #zig
darithorn has joined #zig
xackus has joined #zig
darithorn has quit [Client Quit]
<fengb>
`error: else prong required when switching on type '*fmtgen.Generator([]const u8)'` but I have an exhaustive switch...
<fengb>
Oh oops, I need to switch on self.*, not self
<mq32>
can't you pass the frame storage location from the outside?
<fengb>
Yes but you need to declare the type at the `foo = async func()` site
mahmudov has joined #zig
<mq32>
you can also get the frame type with @Frame()
<fengb>
And to make it easy, that frame needs to exist on the stack somewhere. I can't shove it in a "normal" struct, so I'd need to dump it into a generic built struct
<mq32>
let me think a bit
<mq32>
maybe it can work with result location
<mq32>
i kinda feel like i miss something
<mq32>
but can't you store the frame in a struct returned from genFunction?
<traviss>
shouldn't it be new_align <= old_align ?
<fengb>
Not unless the struct is comptime generic, which I'm trying to avoid
<mq32>
hmm
* mq32
has a crazy idea
<mq32>
nah, forget it
<mq32>
> "can't you store the generator in the frame itself"
<fengb>
This style of generator actually allows any function in the same execution stack to yield to it. I'm not sure if it's better than making generators easier to create / consume, but it definitely make the coding easier
<andrewrk>
traviss, yes it looks like a bug to me too. I think it should be checking against the actual alignment, rather than old_align
<fengb>
Shouldn't old_align be actual alignment?
<fengb>
mq32: I tried that but I don't know how myFunc could yield to the generator. It becomes a weird catch 22 where the function needs somewhere to yield, and the generator needs somewhere to store the frame
<andrewrk>
old_align is the client-tracked value of the old *requested* alignment
<traviss>
ok good news. thanks to Rageoholic in discord for pointing this out.