laaron has quit [Remote host closed the connection]
laaron has joined #zig
brodeuralexis has joined #zig
<scientes>
gd. Debian doesn't build riscv for llvm-9
laaron has quit [Remote host closed the connection]
wilsonk has quit [Remote host closed the connection]
laaron has joined #zig
wilsonk has joined #zig
<scientes>
oh that is actually apt.llvm.org
wilsonk has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
brodeuralexis has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<stratact>
meh, I decided to make my type more generic and useful, that I decided to rename it to StackList, which is like ArrayList, but on the stack.
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<stratact>
Dunno if it would be useful for people to use, but I'm using it for std.fs
<daurnimator>
stratact: if you give your ArrayList an allocator that uses the stack it is on the stack...
<daurnimator>
stratact: you can even use StackFallbackAllocator so that its on the stack most of the time: unless you need extra room...
<stratact>
I'm not allowed to use an allocator though
<stratact>
Oh wait, maybe I can, but inside the caller's stack
<daurnimator>
stratact: you can still have a blob on the stack and use a FixedBufferAllocator inside
<stratact>
Damn, my effort feels somewhat of a waste, but at least now I know how flexible ArrayList is with using the right allocator
hspak has joined #zig
<stratact>
daurnimator: thank you again, your input was very valuable
plumm has joined #zig
<plumm>
ok, is it a hassle to install llvm 9 on mac os?
<daurnimator>
plumm: considering it only came out a couple of days ago, I'm not sure too many people have trodden that path
<plumm>
I've been working alongside zig HEAD so the update today kinda caught me off guard. tried building from llvm head but didnt realize that that was 10, and there arent any ports for 9 yet (or PRs even)
<mikdusan>
verify value of $PREFIX matches llvm location
<mikdusan>
ie: llvm binaries install dir
plumm has quit [Quit: Lost terminal]
porky11 has quit [Quit: Leaving]
donpdonp has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<andrewrk>
daurnimator, recently glibc version has been added as part of the target, when targeting glibc. we also plan to add cpu features as part of the target. so what this will require is adding minimum OS version as part of the target. https://github.com/ziglang/zig/issues/1907
<andrewrk>
"native" will mean whatever OS version is currently running
<andrewrk>
once this is implemented you would be able to do e.g. @import("builtin").linux_version or similar
<daurnimator>
andrewrk: if targetting 5.2+.... what should it do? try new version first then fallback to old (less secure) behaviour?
<daurnimator>
how do you target e.g. 5.2 explicitly vs >=5.2?
<andrewrk>
daurnimator, the setting will be the "minimum OS". Idea being that the software is supposed to be compatible with that version and all versions after
mikdusan1 has joined #zig
plumm has joined #zig
<plumm>
!log
johnLate_ has joined #zig
via_ has joined #zig
<plumm>
ok, mikdusan1 I managed to build llvm 9 but the command for building zig failed within the findllvm cmake. I can run llvm-config myself and get a version, but the output from within the cmake is blank and causes a failure
bbrittain_ has joined #zig
SimonNa has quit [*.net *.split]
mikdusan has quit [*.net *.split]
telemach has quit [*.net *.split]
fgenesis has quit [*.net *.split]
tyler569 has quit [*.net *.split]
johnLate has quit [*.net *.split]
bbrittain has quit [*.net *.split]
letoram has quit [*.net *.split]
via has quit [*.net *.split]
Akuli has joined #zig
tyler569 has joined #zig
SimonNa has joined #zig
bbrittain_ has quit [Ping timeout: 240 seconds]
bbrittain has joined #zig
lunamn_ has quit [Ping timeout: 276 seconds]
TheLemonMan has joined #zig
<TheLemonMan>
andrewrk, if you're trying to run the behavior tests on aarch64 have a look at #3278 first
<andrewrk>
hi TheLemonMan, I was just hoping to find you here
<andrewrk>
question about the undefined pointer test failure -
<andrewrk>
what was the issue here? was it a release-fast build because we set the "nonnull" attr, and passing undef as the parameter violates that?
<andrewrk>
because if not for that I think it should work right? the ptr is never dereferenced
<TheLemonMan>
nope, bog-standard test run in debug mode. The pointer is never deferenced but it's checked as part of the optinal payload
rohlem has joined #zig
<andrewrk>
oh, I see, but the cast assumes non-null. OK that makes sense then. This is a bit of a tricky issue
<andrewrk>
(PR is good, merged)
<andrewrk>
I've been thinking that it would be OK for a slice to have undefined ptr if the len is 0
<TheLemonMan>
the undefined parameter is not lowered into anything at all
<andrewrk>
if an operation can possibly invoke UB depending on the operand's value, and the operand is undefined, then that operation invokes UB
<TheLemonMan>
if you check out the generated code for x64 the %rdi register is never loaded at all once "test" is invoked
<andrewrk>
it means that this is undefined behavior: (?*T)((*T)(undefined))
<andrewrk>
(compile error will catch that one since it's comptime, but you get the idea)
<rohlem>
Wouldn't that still pass as an undefined value, with its optional-ness being undefined?
<andrewrk>
rohlem, ah, yes, that's right.
<rohlem>
This might be tangential or too abstract, but should a callee ever have to check whether an argument is actually a valid bit pattern for that type?
<andrewrk>
that's not a thing that is possible to check
<rohlem>
Because if not then passing undefined as a function argument would require the caller to make that check
<andrewrk>
sometimes it is in debug builds, but that's on the compiler to insert such safety checks
<rohlem>
Or otherwise having any function argument undefined is always UB? I.e. always an error?
<andrewrk>
that's not the case
<rohlem>
Say we pass a non-optional pointer. I see 3 options for checks: Caller checking if it sends a valid arg, callee checking if the arg received is valid, or checking if the argument is non-null on the first use / cast to optional pointer.
<rohlem>
Just hypothetically, if a function call is a "expression with a side effect" and an undefined argument is an "operand", then by # 1947 it would be UB, correct?
<rohlem>
ah, no, it only lists that for "expressions which have possible undefined behaviour", my bad.
<rohlem>
(Again, purely hypothetical - would making `undefined` only "usable" within function scope and "safety-converted" at function boundary be too much of a loss?)
<andrewrk>
I'm not sure exactly what that would look like. we don't have a fool proof way to determine if a value is undefined at runtime
<rohlem>
Well, not in the general case, but we can know for a type with X bits of value and X+P bits of storage what P has to be in order for the operations to behave as they should, correct?
<rohlem>
Or in the case of pointers, there's a single all-zero state that a non-optional pointer should never be in. So we can at runtime determine if a pointer-argument is in this "invalid" state.
<rohlem>
(Undefined and UB are the only way to get that type into that bit pattern, but that's not directly relevant.)
<rohlem>
(* what states the additional P padding bits need to be in)
<andrewrk>
TheLemonMan, wow nice, behavior tests passing for me with aarch64 qemu. I'm going to add build.zig option for this
<andrewrk>
I'll probably remove the original syntax after that, because Foo{.a=b} would be equivalent to Foo(.{.a=b})
<companion_cube>
which looks kind of weird, tbh
<companion_cube>
would `{.a=b}` be an option?
<companion_cube>
then you can specify with `{Foo.a=b}` if needed (as OCaml does)
<andrewrk>
var foo: Foo = .{.a = b};
<companion_cube>
fair enough, yeah
<companion_cube>
what does it look like for unions? exact same syntax?
<Tetralux>
Maybe Foo.{.a = b} too then?
<Tetralux>
That way transforming code would be more pleasant.
<andrewrk>
if {.a=b} is unambiguous with only 1 token look ahead I think that would be a reasonable candidate. but it breaks consistency with anon enum literals `.foo` & anon list literals `.{a, b}`
<andrewrk>
I wanted [a, b] for anon list, but it's ambiguous with array types (a can be an entire expression)
<andrewrk>
{a, b} is ambiguous with blocks
<companion_cube>
so I ported a bit of hairy C to rust, with unsfe pointers everywhere
<companion_cube>
and I think Zig would be so much more suited to this
<andrewrk>
I do feel confident saying that zig is better suited for the parts of a rust codebase that would have to be unsafe anyway
<andrewrk>
when your unsafety doesn't have an explicit seam, zig is pretty good
<andrewrk>
(a, b) is ambiguous with grouped expressions
<andrewrk>
so .{a, b} it is
<companion_cube>
yeah, if most of the code is unsafe anyway…
<companion_cube>
I do miss rust's syntax a bit though
<companion_cube>
(yeah, I'm repeating myself)
<_Vi>
Is there already a proposal issue about exposing distributed enum mechanism Zig uses for error handling to be available for other purposes?
<companion_cube>
I'd call that "open enum" personally (as in OCaml… predictably)
<_Vi>
Otherwise errors would be misused as poor man's "open enums", with tricks in `errdefer` to run only on genuine errors.
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<companion_cube>
(funny, that's how exceptions work in OCaml as well; after open sum types were introduced, exceptions became just another normal defined type)
<Sahnvour>
andrewrk: are you still considering PR before the release of 0.5.0 ?
mikdusan1 is now known as mikdusan
porky11 has quit [Quit: Leaving]
<_Vi>
Was idea of number types with a niche for null already proposed/considered?
<rohlem>
_Vi, to clarify, you propose that f.e. `@bitSizeOf(NicheNullable(uX, 0xFF)) == @bitSizeOf(uX)` ?
<rohlem>
For now I guess a userland `fn is_niche_null(uX) bool` , or wrapper (generic) struct to avoid ambiguity would be a replacement solution.
<rohlem>
Operating on such NicheNullable integers would either require unwrap-if-s before every value access, or adding overloads (with additional cause of failure) for every integer operator to the language.
drazan has quit [Remote host closed the connection]
drazan has joined #zig
<_Vi>
rohlem, Yes.
<_Vi>
rohlem, In Rust, NonZeroU{..} just always requires casting to regular numbers for any operations. NonZero... is only for storage and it is UB to cast 0 to them.
<_Vi>
rohlem, More like `@bitSizeOf(? NicheNullable(uX, 0xFF)) == @bitSizeOf(uX)`
<rohlem>
_Vi, wouldn't that make the NicheNullable nullable a second time? Given current semantics, if you implement NicheNullable via a generic struct.
<_Vi>
rohlem, Don't understand. Or do you mean `NicheNullable` already having optional semantics (`try` `orelse` and so on)?
<_Vi>
The idea is to make using sentinel value ergonomic.
<rohlem>
The `?` prefix operator adds an additional layer of nullable. `?T` is already a nullable type.
<rohlem>
Whatever NicheNullable returns would get an additional layer of nullable-ness. I would assume that's what NicheNullable does already.
<_Vi>
So `? NicheNullable(uX, 0xFF)` is optional non-FF number. `NicheNullable(uX, 0xFF)` is just non-FF number, not optional.
<rohlem>
Given something non-optional a name containing `Nullable` strikes me as counter-intuitive.
<_Vi>
So that `NicheNullable` is not a good name. More generic version of the feature is range-restricted types like that is said to exist in Ada.
Ichorio has quit [Ping timeout: 245 seconds]
<rohlem>
The blacklisting of certain values is an additional feature you're proposing. The closest status-quo thing I can think of is not exhausting all states of an enum's tag type. As in `enum(u2){A,B,C}`.
<_Vi>
But the latter is more often cited for additional correctness checks rather than for layout opt.
stratact has quit [Remote host closed the connection]
<rohlem>
Making the compiler then look for invalid bit patterns to use as nullable-flag/counter is powerful, but probably goes against the `simplicity` principle.
<rohlem>
Though with comptime evaluation and reflection, you're free to implement such a mechanism in userspace - although that of course doesn't include syntactic sugar.
<_Vi>
Typically sentinel values are at the end of supported value range. So range-limited numbers can emulate niched numbers for 2 values of the niche per type.
<_Vi>
Yes, adding more layout optimisations (extending existing "optional pointer") is definitely less simple.
<_Vi>
And it may be impossible anymore if there will be stable commited Zig ABI.
<rohlem>
The idea of preprocessing steps has been toyed around with however.
<rohlem>
Especially with the self-hosted compiler being a part of the standard library, maybe there can be a fork that allows adding custom type operators and more backend logic.
<rohlem>
Then you could have ".zig_custom" files in your repository, have the build.zig process it via a slightly modified pre-parser or compiler, and integrate that with the rest of your code base. (Or have no vanilla Zig left even.)
<_Vi>
Very powerful, but explicit idea is fully customized layout: user-defined functions to write to memory and read from memory to store/retrieve a particular Zig struct/enum/union.
<rohlem>
... if you want fully customizable memory access, you're kind of bypassing the type system at that point. At least its layout.
<_Vi>
I.e. custom representations: not C-compat, not packed, not SIMD, but really custom.
<_Vi>
One can instruct to store a number in stack or heap e.g. xor-ed with some constant (and only have "unencrypted" number for short amount of time in registers).
<_Vi>
Imagined use case: video game with a slight anti-cheat debugging resistance against memory scanning.
<rohlem>
That sounds unnecessarily complicated. Wouldn't an extensible obfuscation framework be better suited?
stratact has joined #zig
<_Vi>
Would this framework automatically work for wasm and mips?
<rohlem>
I'd assume you want the code you write to be somewhat readable, right? So add obfuscation steps before, during, or after compilation that XOR, shift, and throw about magic values.
<rohlem>
But I don't see the point in hard-coding something like that into the source code. That will only make your life harder.
<_Vi>
Obviously, the code should be fully readable, as if there is no tricky layout/memory indirection layer.
<andrewrk>
Sahnvour, re: "are you still considering PR before the release of 0.5.0 ?" yes if it's easy to merge
<_Vi>
The complexity should be in custom sizeOf, alignOf, read and write functions.
<rohlem>
I honestly don't understand / agree with the use case of "cheat prevention via obfuscation". But if you plan to obfuscate, it should IMO be at a layer after business logic. Otherwise you're confusing yourself just as much as reverse-engineers / "attackers".
<rohlem>
So keep your source code clean and readable, and during an obfuscation step then assign every logical entity you want to treat distinctly - like every struct's member - some unique ID, then randomly prepare a map of de- and serialization routines from and to instances of such an entity.
<_Vi>
rohlem, Maybe compressed-ish memory storage would be better use case.
<rohlem>
For compression you probably want to just use packed struct, and if you know some invariant to save space add set- and get-methods that are aware of how to compress.
<andrewrk>
I feel comfortable saying obfuscation is not one of the accepted use cases of zig
<companion_cube>
:D
<_Vi>
Anyway calling user code on reads/writes of specified type from/to memory can be considered "implicit control flow" which is avoided in Zig...
<companion_cube>
write reusable code… by obsfucating it!!
<_Vi>
Simple things (if return closer to the beginning of the discussion) is just to provide nonZeroU16, nonFfffU16, nonMinvalI16 and so on, for specific sentinel values only.
plumm has quit [Read error: Connection reset by peer]