forgot-password has quit [Ping timeout: 260 seconds]
<metaleap>
lsp progress for the day: got the symbols-listing/hierarchy/outline to a useful-enough (and seemingly unbugged for now) state for me https://i.imgur.com/kBbZLp8.png
<metaleap>
with that and fmt in place, finally can move on to the harder but higher-payoff features.
AndroidKitKat has quit [Quit: バイバイ〜！]
AndroidKitKat has joined #zig
tane has quit [Quit: Leaving]
frmdstryr has quit [Remote host closed the connection]
lqd has quit [Quit: Connection closed for inactivity]
metaleap has quit [Quit: Leaving]
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 260 seconds]
mforney has quit [Excess Flood]
mforney has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 258 seconds]
<pixelherodev>
So I had a bright idea which is probably going to make life a lot easier: going through the upstream LLVM lexer to ensure mine matches its behavior :)
<pixelherodev>
Was actually more interested in the AST than the lexer, as I was having a bit of trouble working out a good design for the AST
ave_ has quit [Quit: Connection closed for inactivity]
procnto has quit []
procnto has joined #zig
<pixelherodev>
Hmm. So apparently, enums don't show up in gdb correctly :(
<pixelherodev>
`print token.token_type` -> `.TailMarker`, but stepping through the code it follows the correct path
<pixelherodev>
That is, the value is correct, but GDB reports it incorrectly
<pmwhite>
That was my experience as well.
<pixelherodev>
pmwhite, any suggestions?
<pixelherodev>
Ah, found a way
<pixelherodev>
Take the address, cast to enum tag type, dereference
<pmwhite>
I never actually worked around it, so that's helpful.
<pmwhite>
Is gdb scriptable at all? Like, could you make a custom command or something for that?
<pixelherodev>
I think so?
<pixelherodev>
Found the root of the problem though
<pixelherodev>
The address is wrong
<pmwhite>
Not sure if that would save much effort.
<pixelherodev>
That is, if you have `const a = struct { b: ENUMTYPE }`:
<pixelherodev>
Where A is an instance of `a`: `print *(unsigned char*)(&A)` gives the correct result, but `print *(unsigned char*)(&A.b)` doesn't
<pixelherodev>
because the address of A.b in the debug info is incorrect'
<pixelherodev>
Filing bug report now
Barabas has quit [Ping timeout: 260 seconds]
mforney has quit [Excess Flood]
mforney has joined #zig
<pixelherodev>
What's the difference between `const a: fn()void` and `const a: (fn()void)*`?
<daurnimator>
You're about to multiply the second one? :P
<pixelherodev>
Rephrase: are they both just function pointers?
<daurnimator>
The second one is going to be a compile error isn't it?
<pixelherodev>
I don't think so
<pixelherodev>
IIRC that's what I used for something in my kernel
<pixelherodev>
But I haven't touched that in a while so...
<daurnimator>
did you mean `const a: *(fn()void)`
<pixelherodev>
Retraction: nope, it's not
<pixelherodev>
Yeah
<pixelherodev>
Would that be a pointer to a function pointer, or a function pointer?
<pixelherodev>
function pointer or a pointer to one *
<pmwhite>
Former
<pixelherodev>
Alright, thankses
<pmwhite>
Fn types are already function pointers I believe.
<pmwhite>
Because you can't move function values, so they always have to be pointers.
<pixelherodev>
Right, makes sense
<pixelherodev>
Just wanted to clarify
<pmwhite>
So there is no point to adding extra syntax to indicate that it is a pointer. This is my understanding anyway.
<daurnimator>
pmwhite: so..... why *can't* you move function values?
<daurnimator>
like.... I should be able to do: `const func = try mmap(...., @sizeOf(somefunc), ... │PROT_EXEC,....); func.* = somefunc; func.*();`
<pixelherodev>
Relative addresses will be incorrect
<pixelherodev>
Simply put, it requires ABI guarantees which don't exist
_whitelogger has joined #zig
<pmwhite>
Not sure what the use of moving function would be anyway.
<pixelherodev>
Well, combined with CRNG, could be used for security?
<pixelherodev>
Have a hook at the beginning of main that automatically relocates all functions to randomized offsets, rewriting addresses
<pixelherodev>
s/addresses/addresses *within the functions*
<pixelherodev>
that is, if main calls `a()`, and a is relocated to DEADCODE, the call would be rewritten
<pixelherodev>
I am explicitly not saying this is a good idea
iohzrd has joined #zig
<pmwhite>
As in, you are making no judgement of its goodness?
<pixelherodev>
s/.*/This is definitely a bad idea though/
<daurnimator>
pixelherodev: note the `--bundle-compiler-rt` argument: it should have bundled it in.... but I don't see it there
<pixelherodev>
Ahh, right
iohzrd_ has quit [Quit: iohzrd_]
* pixelherodev
shrugs
return0e has quit [Ping timeout: 255 seconds]
return0e has joined #zig
marmotini_ has joined #zig
marmotini_ has quit [Ping timeout: 255 seconds]
_whitelogger has joined #zig
slowtyper has quit [Quit: WeeChat 2.7]
slowtyper has joined #zig
dddddd has quit [Remote host closed the connection]
return0e_ has joined #zig
return0e has quit [Ping timeout: 272 seconds]
hobomatic has joined #zig
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
metaleap has joined #zig
slowtyper has quit [Ping timeout: 272 seconds]
slowtyper has joined #zig
neceve has joined #zig
mahmudov has joined #zig
<daurnimator>
Why is riscv32 tier 4 instead of tier 3?
slowtyper has quit [Quit: WeeChat 2.7]
forgot-password has joined #zig
<Snektron>
In what situation would Allocator.realloc be called with new_size < old_mem.size ?
<Snektron>
I noticed that in PageAllocator, realloc just calls shrink if thats the case, and the new alignment is smaller (or equal)
<Snektron>
But every buffer returned by the PageAllocator should be page aligned right? So that would mean shrink can be called if the new alignment is smaller or equal to the page alignment (or whatever alignment the buffer just happened to be)
<Snektron>
assumed old_align is the alignment requested on the previous alignment and not what the buffer happened to be
<Snektron>
I think something is wrong with my linux installation, because if i recompile Zig it starts to rebuild everything regardless of what changed
<mikdusan>
hmm... I've only ever seen "unconditional-like" rebuilds when system clock has been changed radically, or something wrong with it (not in zig build specifically, just depenendencies in general)
<mikdusan>
sometimes a network share is involved
forgot-password has quit [Ping timeout: 255 seconds]
<Snektron>
mkdusan, i've noticed it happens with other projects as well
<Snektron>
The strange thing is that its usually fixed if i use gcc instead of clang
<Snektron>
but not with Zig
<mikdusan>
.ccache ?
<Snektron>
afaik my system clock is normal, and everythink is on my local ssd
<Snektron>
I'm not using ccache on either my laptop or desktop
<mikdusan>
any special filesystem mounting options used?
<Snektron>
not that i know of
<Snektron>
Does zig support va_arg functions yet?
<mikdusan>
this is a very generic lead; maybe whatever file is in the dependency chain being updated, is not actually being updated because of some permissions problem
<Snektron>
hmm, maybe
<Snektron>
i'd expect something to throw an error about not being able to write that file though
<mikdusan>
"rebuild everything" . do you mean using zig.exe to build things, or using cmake/clang to build zig.exe ?
<daurnimator>
Snektron: you mean why would you shrink memory?
<Snektron>
daurnimator, i mean why would i shrink memory with realloc
<daurnimator>
Snektron: e.g. you have an hashmap have removed some entries: you may want to give up some space back to the OS; but if it fails, you don't mind and having extra space is fine
<daurnimator>
Snektron: the key point is: realloc is allowed to fail; shrink is not allowed to
<Snektron>
mikdusan, it looks like its actually not recompiling the entire think, just 146 objects
<Snektron>
daurninator, but why would i call the function thats allowed to fail instead of the one thats not allowed to fail?
<daurnimator>
Snektron: because it could be faster.
<Snektron>
ah, thats a valid reason
<daurnimator>
also: shrink might "not fail" by just lieing about freeing the memory
<Snektron>
anyway, suppose i have a c function that accepts a parameter via a c vararg. Can i `extern` that function in zig?
<Snektron>
Its about mremap in this case, it accepts an optional parameter
<daurnimator>
Snektron: uh..... sometimes: sometimes it works; other times I've gotten errors with TODOs in them
<Snektron>
hm
<Snektron>
Should i just use the syscall regardless of whether c is linked?
<Snektron>
s/c/libc/
<daurnimator>
no?
<daurnimator>
Are you sure its actually a vararg and not a weird thing like open() ?
<Snektron>
no its really a vararg
<daurnimator>
looks like a weird thing like open() to me
<mikdusan>
Snektron: another hint: I manually set some random .cpp files in zig's source tree to a future timestamp in '2021. It rebuilds them everytime.
<daurnimator>
Snektron: but I have a hunch it will "just work" for you anyway
<daurnimator>
Snektron: give it a go :)
<Snektron>
daurninator, i see what you mean with the weird think like open, but im not sure whats the difference between a c vararg that is used as optional or used as an actual vararg
<Snektron>
mikdusan, i think i'm just going to live with it for now
<mikdusan>
if you have an idea which source .h/.cpp files are being recompiled, take a long listing and eyeball their timestamps
<mikdusan>
but ok
<Snektron>
yeah but like i said, its not limited to zig
<Snektron>
hmm, looks like lld
<Snektron>
time stamps arent in the future or anything
<mikdusan>
yeah but it could be any file in the dep chain that causes this. llvm headers, libs, whatever. anyhow, I'll leave it at that; this smells like a timetsamp issue
<Snektron>
I've just enabled ZIG_FORCE_EXTERNAL_LLD so that it skips building LLD, that saves enough time such that its not as bothersome
<Snektron>
daurnimator, it didn't work. I suspect its because the last parameter of mremap is a pointer
<daurnimator>
Snektron: can you share the code?
<Snektron>
ah, nevermind, i passed a zig type instead of a pointer
<mikdusan>
Snektron: assuming no network mounts search from root and if that comes back empty then I lead you on a wild goose chase: (touch now.txt; find / -newer now.txt)
<Snektron>
that returns a whole bunch of /proc and /sys paths
<mikdusan>
`find /home /usr` should do it
<Snektron>
nothing apart from some misconfigured directory permissions which don't coincide with anything related to zig
<mikdusan>
I'm out of ideas :(
<Snektron>
well with the cmake flag it at least its not so bad now, and i'll probably need to get a new laptop soon-ish anyway so its fine. Thanks for the help
forgot-password has joined #zig
<daurnimator>
Snektron: I assume you'll send a PR to the std lib?
<Snektron>
Yes
shakesoda has quit [Quit: Connection closed for inactivity]
hobomatic has quit [Remote host closed the connection]
forgot-password has quit [Ping timeout: 258 seconds]
<mq32>
brain fart: error: type '@TypeOf(.Environment.init).ReturnType.ErrorSet!.Environment' does not support field access
<mq32>
this error message may have an additional "Check if you forgot to catch an error" text or something
waleee-cl has joined #zig
mahmudov has quit [Ping timeout: 260 seconds]
dddddd has joined #zig
forgot-password has joined #zig
forgot-password has quit [Client Quit]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<daurnimator>
I just updated to latest zig master and things seem to be broken....
<daurnimator>
running tests for a module I have around I get: Segmentation fault at address 0x0. ???:?:?: 0x0 in std.target.Set.empty_workaround (c)
<daurnimator>
oh. I was missing -lc
<mq32>
oh
<mq32>
std.fmt.format isn't able to print recursive structures anymore
<mq32>
is there an issue for that already?
Thalheim has quit [Ping timeout: 268 seconds]
decentpenguin has joined #zig
daex has quit [Ping timeout: 258 seconds]
daex has joined #zig
shakesoda has joined #zig
decentpenguin has quit [Quit: decentpenguin]
wootehfoot has joined #zig
stereosteve has joined #zig
<dimenus>
am i blind or do we not have a strlen equivalent in the stdlib?
<frett27_>
Note that programs using C++ object files must always be linked with g++, in order to supply the appropriate C++ libraries. Attempting to link a C++ object file with the C compiler gcc will cause "undefined reference" errors for C++ standard library functions
<frett27_>
leveldb is a c++ library
<frett27_>
with c headers
<frett27_>
but i'm not sure i can link both, if it needs cpp linker
iohzrd has joined #zig
_Vi has quit [Ping timeout: 272 seconds]
<jessermeyer>
Still curious about my PDB question.
<frett27_>
mq32: finally, was missing a libc++abi-9-dev, works with this command line : ../zig/zig test levedbtest.zig --verbose-cc -lleveldb -lc++ -lc++abi -lc
<frett27_>
jessermeyer: don't know
<jessermeyer>
Wanting to get a hunch from folks here before spinning up an Issue on the repo.
iohzrd has quit [Quit: iohzrd]
<pixelherodev>
I'd report the issue
<jessermeyer>
Roger that.
<jessermeyer>
BTW, anyone following the ALSR discussion on the PIE issue? Am I off base?
<jessermeyer>
ALSR for buffer overrun protection strikes me as extremely heavy handed compared to alternatives, but I cannot deny the benefit.
<andrewrk>
ASLR is standard in most linux distributions
<andrewrk>
I think it's an appropriate default for ReleaseSafe mode
<jessermeyer>
If the goal is to adhere to standards, whatever they are, then there isn't much room for discussion.
<andrewrk>
I think you misunderstand me
<andrewrk>
being standard in most linux distributions is an argument for ASLR not being too heavy handed, and for it being an appropriate default for ReleaseSafe mode
_Vi has joined #zig
<jessermeyer>
'Too heavy handed' is with reference to the threat model when ASLR was implemented, which was before spectre, meltdown, etc.
<jessermeyer>
I would be shocked if the Linux kernel would have invested in ALSR if it knew its value would be limited to buffer overruns. It was designed for a different problem.
<jessermeyer>
I expect to see ASLR rolled back over time, or until the cache model for modern CPUs changes somehow.
<andrewrk>
I do not expect to see this
<jessermeyer>
What do the impacts of that paper tell you about the viability of ASLR as a security measure? https://www.vusec.net/projects/anc/
<shakesoda>
didn't run into anything weird with integrating the c++ stuff in the build
<shakesoda>
now i can think instead about making something useful show up on screen ;)
<jessermeyer>
nice!
metaleap has quit [Ping timeout: 240 seconds]
rjtobin has joined #zig
<andrewrk>
jessermeyer, ASLR was never understood to be foolproof. it's a hardening measure
<andrewrk>
the exploit in that article requires ability to run turing complete code in a sandbox, btw, which is not always available to an attacker. one might even say rarely available to an attacker
<jessermeyer>
My argument is that its hardening measure is substantially less in the presence of these exploits.
<jessermeyer>
Agreed. The article is specific to web browser security.
<jessermeyer>
I'm not well versed on what to assume attacker capabilities are. No idea.
<jessermeyer>
But if an attacker is leveraging a buffer overflow (which comes from the discussion in the thread), we are in a turing complete scenario, so I think we can assume that capability, I think for Zig broadly.
<gchristensen>
[citation needed]
<jessermeyer>
For which claim?
<gchristensen>
buffer overflow -> turing complete
<jessermeyer>
I forget how many bytes of overrun you need to take complete control of the execution pipeline. I recall Chandler Carruth specifying this in one of this security talks ... Let me find that.
<andrewrk>
typically as an attacker you need to hard code a (correct) address when exploiting a buffer
<jessermeyer>
Yes, which AFAIK, can be determined with this new side channel attack.
<jessermeyer>
Or are you saying you need a turing machine to run the attack in the first place?
ur5us_ has joined #zig
decentpenguin has joined #zig
<gchristensen>
that attack seems to require turing completeness in the uncompromised environment to pull off
<gchristensen>
most buffer overflow attacks are much less exotic and aslr is an effective solution
<gchristensen>
I'm looking forward to processors implementing capability-based security, revoking the authority to jump to those pointers -- like that early experimental intel chip.
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<jessermeyer>
Thanks for the discussion on this topic. Things for me to think and read more about.
ur5us__ has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
<jessermeyer>
I can't find where Carruth made his claims about turing complete attacks, but I did find the related paper. Reading it.
<jessermeyer>
"Unlike previous attacks, ours combines a large number of short instruction sequences to buildgadgetsthat allow arbitrary computation. We show how to build such gadgets using the shortsequences we find in a specific distribution ofgnulibc, and we conjecture that, because of theproperties of thex86 instruction set, in any
<jessermeyer>
sufficiently large body ofx86 executable code there willfeature sequences that allow the construction of similar gadgets. (This claim is our thesis.) "
ur5us_ has quit [Ping timeout: 240 seconds]
<jessermeyer>
I don't know how these results from 2007 have survived, and how they are to be considered in light of side-channel attacks.
dingenskirchen has joined #zig
<jessermeyer>
'... argument applies to the interaction between our techniques and address space layoutrandomization (ASLR). Those gadgets that do not require knowledge of addresses on the stack canbe used directly in the Shacham et al. [26] derandomization framework. Some of those gadgets thatdo require knowledge of addresses on the stack could likely be
<jessermeyer>
rewritten not to require it'
<jessermeyer>
~in light of _modern_ side channel attacks
frett27_ has quit [Ping timeout: 265 seconds]
jessermeyer has quit [Remote host closed the connection]
ur5us__ has quit [Remote host closed the connection]
nepugia has joined #zig
rjtobin has quit [Remote host closed the connection]
jjido has joined #zig
jessermeyer has joined #zig
waleee-cl has joined #zig
metaleap has joined #zig
decentpenguin has quit [Quit: decentpenguin]
Akuli has quit [Quit: Leaving]
<metaleap>
whats the deal with std.Mutex.deinit()? all 3 defs of it in std/mutex.zig have the same `self.* = undefined;` no-op-ish logic
<metaleap>
wouldnt like to turn all my `defer held.release()`s into `defer { held.release(); held.deinit(); }` if it's not ever actually going to do any *real* cleanups.. am i missing sth?
<fengb>
In safe mode, it’ll set the memory to 0xaaaaaa and probably crash if it’s reused
wootehfoot has quit [Ping timeout: 260 seconds]
<metaleap>
fengb: makes sense thx
<mq32>
i don't think requiring a mutable reference for deinit is a good idea
<mq32>
this enforces variables that never be mutated to be non-const
ur5us has joined #zig
frmdstryr has joined #zig
wootehfoot has joined #zig
rjtobin has joined #zig
neceve has quit [Ping timeout: 260 seconds]
wootehfoot has quit [Ping timeout: 252 seconds]
jessermeyer has quit [Remote host closed the connection]
<andrewrk>
mq32, deinitializing them is mutation
<andrewrk>
metaleap, zig's safety features do not yet take advantage of this, but there are quite a few things where setting things to undefined will activate safety protections
<andrewrk>
for example, branching on undefined. `x = undefined; if (x) ` will cause a safety panic
<metaleap>
sounds good
<mq32>
hm. maybe i think too c++y for this...
<shakesoda>
it seems reasonable to keep it mutable in the scope you own it and pass it around as const if needed
<shakesoda>
that's what i've been doing
<shakesoda>
seems natural enough?
MajorLag has joined #zig
tgschultz has quit [Ping timeout: 260 seconds]
MajorLag is now known as tgschultz
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
adamkowalski has joined #zig
<adamkowalski>
suppose somebody gives you a nested anonymous struct like so .{ .{ 1, 2, 3 }, .{ 4, 5, 6 } } into a var parameter. How do I detect properties about it's length and element type?
<adamkowalski>
do I need to look at the type info and check the fields to see if each one is of the same type, and count the number of fields?
dimenus has quit [Ping timeout: 268 seconds]
rjtobin has quit [Remote host closed the connection]
<metaleap>
adamkowalski: yes. `inline for (@typeInfo(@TypeOf(my_var_arg)).Struct.fields)`
mahmudov has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 240 seconds]
<Cadey>
hey andrewrk do you know what kind of insane bullshit hackery would be needed to get Zig to build binaries that TempleOS can use?
<mq32>
Cadey: Convert ELF files to whatever binary format TempleOS uses
<mq32>
also write your own syscall wrapper with a freestanding target