ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
daurnimator[m] has quit [Write error: Connection reset by peer]
dtz has quit [Remote host closed the connection]
JinShil has joined #zig
reductum has quit [Ping timeout: 245 seconds]
<JinShil>
Hello. I'm wondering if Zig has any plans for memory safety either by providing language features or through libraries. Language could include something like a borrow checker or lifetime annotations, library features could potentially be smart pointers.
<benjikun>
isn't borrow checking a rust thing?
<benjikun>
someone can correct me if I'm wrong but I think andrew said it's out of zig's scope for now
<JinShil>
I'm sure some kind of smart pointer implementation can be built in zig, but I'm wondering if anyone on this channel knows about any broader plans for zig.
<JinShil>
Yes it's a Rust thing. I'm not aware of any other language that has a borrow checker.
<JinShil>
Liftime annotations exist in D.
<benjikun>
I'm not sure about what lifetime annotations are
<JinShil>
In D lifetime annotations are keywords `scope` and `return` that tell a function that a reference cannot escape (scope) or can and whose lifetime is tied to the return value (return)
<ibebrett>
as the project notes, hopefully I can find some type of allocator that will be useful to the wider zig community, but I was wondering if anyone wanted to read some of the code there and give some tips
<ibebrett>
I'm pretty sure I'm doing some things in a cludgy way
<daurnimator>
ibebrett: your buffer is global yet you can have multiple allocators.
<ibebrett>
would making the IdioticAllocator struct not "pub" be the right way to "seal it off"
<benjikun>
I think that's on purpose
<ibebrett>
or is there a way to make a "one of",
<ibebrett>
or is it better in this case to just write the code with out a struct at all
<daurnimator>
ibebrett: yeah make it not pub. or bring the buffer into the struct...
<daurnimator>
ibebrett: also your bufferSize choice is incorrect
<daurnimator>
s/choice/check/
<benjikun>
>=
<benjikun>
?
<daurnimator>
benjikun: need to check if(n+self.index >= bufferSize)
<daurnimator>
currently missing the `n + `
<benjikun>
oh true
<daurnimator>
ibebrett: something I'd do is make the IdioticAllocator a function that returns the struct to make the bufferSize a parameter
<ibebrett>
so here is my newbishness
<ibebrett>
to make the bufferSize a parameter
<ibebrett>
would that be something i'd be able to do with the way I've declared buffer?
<benjikun>
no you would have to move the buffer into the struct
<benjikun>
if you had multiple instances of IdioticAllocators, they would write over each other
<benjikun>
with how it is currently
<ibebrett>
yeah, as you noted before I intended to only have one
<ibebrett>
but I don't really have a strong design for this up front, I think doing what daurnimator is saying makes sense to me as
<ibebrett>
I didn't really have a design for this "IdioticAllocator" and exposing it with the size as a param allows it to "land" in the library as at least
<ibebrett>
some fake allocator that just uses the stack
<benjikun>
fair enough
<ibebrett>
stuck on one small thing
<ibebrett>
so if within the struct i have say buffer: []u8, can i initialize that with a "comptime" size
<ibebrett>
so in the init function have something like: pub fn init(comptime bufferSize: usize) { ... return { .buffer = []u8{0} ** bufferSize } }
<daurnimator>
ibebrett: they're different structs.
<daurnimator>
(if you return them from a function)
<ibebrett>
interesting
<daurnimator>
ibebrett: essentially you can write a function that creates structs. it's not too different from C where you could write with the preprocessor: #define IdioticAllocator(size) struct{char buffer[(size)];size_t index;}
<benjikun>
I would make the alloc function take a `self: *Self`
<benjikun>
and avoid using @fieldParentPtr
<daurnimator>
benjikun: huh? that allocFn is a callback
<benjikun>
oh can you not change the parameters on those
<ibebrett>
well anyway, as you said daurnimator, "keeping" the outer struct worked
<ibebrett>
so i dunno if the compiler cant determine i have that reference in terms of what goes on the stack
<daurnimator>
ibebrett: took me a while to see what was happening.... seems like a bit of a footgun. I wonder if there's anything we could do to at least raise a warning...
<ibebrett>
dumb question, but say it didn't have to use
<ibebrett>
@fieldParentPtr
<ibebrett>
would that be enough to cause zig to not "throw out" the data
<MajorLag>
daurnimator, it's a known issue, andrew has ideas but nothing is in yet to deal with that kind of problem. I experimented with a debug saftey feature but it just didn't work properly.
<MajorLag>
ibererett, @fieldParentPtr doesn't do any magic, it just handles the pointer arithmetic for you to turn the *Member to *Parent.
<daurnimator>
MajorLag: I think some sort of "don't copy" mark on a struct member would work.
<benjikun>
ibebrett: It would force you to keep track of the entire struct so in a way yes
<MajorLag>
daurnimator yeah, that's one of the things he mentioned recently, though I don't remember in what issue.
<MajorLag>
but it would also mean the allocator couldn't be used anymore, since things that take an allocator expect *Allocator, not *MyAllocatorImpl
<MajorLag>
that last bit was for benjikun
<benjikun>
yea
<benjikun>
I realized that when daurnimator brought up it being a callback thing
<daurnimator>
ibebrett: btw, you don't take alignment into account
<daurnimator>
I'm suprised we don't have a arg-not-used warning
ibebrett has quit [Ping timeout: 256 seconds]
Thalheim has joined #zig
suirad has joined #zig
<suirad>
howdy
<benjikun>
hiya
<presiden>
hola
<suirad>
whatcha working on?
<benjikun>
programming a shoot em' up type game
<suirad>
nice what in?
<benjikun>
zig :p
<benjikun>
SDL2
<benjikun>
just started an hour ago or so
<presiden>
solving project euler
<benjikun>
presiden: what problem are ya doin?
<presiden>
all of them?
<presiden>
well, wip
<benjikun>
I meant what are you on
<presiden>
still in 20-30
<benjikun>
ah
<suirad>
i have an idea for a simple leak detecting allocator, that you could use to wrap another allocator you are using in a fn to detect any leaks. am probably going to implement it.
<presiden>
using projecteuler mainly for learning the ins and out of new language
<benjikun>
I see presiden
<benjikun>
suirad: sounds cool
<suirad>
we've got to get those github repo counts up for syntax highlighting, and making small useful libraries could help
<benjikun>
true, we're almost there
<presiden>
that's the plan anyway, tho I only got as far as 50-ies or something
<presiden>
on other language
<suirad>
Ive also been thinking about what stuff thats useful/commonly used in c++ to make that could help productivity. I am a prefer C, but usually when I talk to someone who prefers c++ the usually like to say how quickly they can stark work using std stuff.
<suirad>
thats why i made the refcount/shared_ptr equivalent thing before and started trying to make something similar to a unique_ptr
ibebrett has joined #zig
ibebrett has quit [Client Quit]
<daurnimator>
andrewrk: watching from the shadows? :) just saw #1790
<suirad>
lol
reductum has quit [Quit: WeeChat 2.3]
<suirad>
anyone there?
<benjikun>
I'm here
<benjikun>
what's up?
<suirad>
If im making a debugging tool, should i also support releasesafe? im having it give a compile error for anything other than debug mode
<suirad>
i can also just optimize out
<benjikun>
not sure
<benjikun>
why not support releasesafe?
<suirad>
its a simple leak detecting allocator. essentially im going to keep an atomic count of allocations/frees. then on .deinit panic if not allocation_count != 0
<suirad>
lol
<suirad>
if allocation count is 0
<suirad>
lol sorry its late
<suirad>
panic if allocation count isnt 0 on deinit
<benjikun>
it's fine :p
<benjikun>
I would probably let it work on releasesafe
<suirad>
its an allocator that wraps another allocator that you pass to it in .init
<suirad>
and since you pass in another allocator, i could on releasefast/releasesmall, just make my alloc/realloc/free fn pointers just point to the allocator that i am wrapping
<suirad>
after talking about it out loud, making it just optimize out would probably be for the best
<suirad>
once i get it working, ill add a feature to allow a # of leftover allocations to pass, so you can keep allocated values but keep the safety
<suirad>
should i panic or return an error when a leak is detected?
<benjikun>
either would be fine, but I would return an error
<benjikun>
I reserve panics for things that are immediately fatal and or need stacktraces
<suirad>
would a leak not meet that criteria?
d_s_ has quit [Read error: Connection reset by peer]
<benjikun>
idk if a stacktrace would be relevant because it points to where the panic is
<benjikun>
aren't you waiting until the final deinit to check
<suirad>
yes
<benjikun>
meh, up to you
<suirad>
im thinking of moving my 'check for leak' portion of .deinit to a fn called .checkLeak that raises if a leak is detected. Then changing .deinit to call .checkLeak and panic if it raises
<suirad>
hmm raising was nice to have in testing though...
<suirad>
i think i'll keep it a raise for sake of simplicity and testing
<suirad>
benjikun: im done for tonight if you want to check it out
<ducktype>
the cast shound convert usize to u32 i think
<andrewrk>
zig won't cast automatically because it could destroy numerical information
<ducktype>
var real_euid = std.os.linux.geteuid();
<andrewrk>
so you have to choose a destructive cast @truncate or an assertion cast @intCast
<ducktype>
should infer the correct type
<ducktype>
i'm not specifying the type explicitly
<andrewrk>
the return type of geteuid is usize. but the man page for geteuid says "these functions are always successful." so I think it would be ok to do the @intCast in the implementation of geteuid
<ducktype>
so i need to change zig lib source code?
<andrewrk>
ducktype, yes, you can make the contribution, or you can file an issue, and work around in the meantime with @intCast
<ducktype>
ty
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<very-mediocre>
I wonder if zig's future package manager could employ some strategy to mitigate such a risk
<very-mediocre>
in an idea world, desktop OSes would do what mobile OSes do with application manifests that describe certain permissions / url whitelists etc
<andrewrk>
zig's plan is for decentralized package management, where everything is locked in all the time with hashes. We'll have tools that help you upgrade to new versions of software, and help make decisions such as which versions to update to and how to determine the trustworthiness etc
<andrewrk>
with zig package management, your software dependencies don't change until you decide to do the work of upgrading them. and then at that point plz use the tools to help you upgrade safely
<very-mediocre>
interesting, what kinds of strategies do the tools use for this?
<very-mediocre>
it seems hard to assess what kind of change is a malicious one. It'd be nice if there were a manifest of some kind that you'd diff when upgrading, to see if additional "permissions" were added, but this seems to be the OS's job
<very-mediocre>
(meaning "permissions" are OS-specific so this would only work in a locked down OS with a standard set,, e.g. mobile)
<andrewrk>
tools for determining API / ABI compatibility, tools for determining what forks of packages are available, potentially the concept of "trusted maintainers" with signed pub keys, etc
<very-mediocre>
I see!
<very-mediocre>
I feel like I'd want to be warned if anything that does an "external" operation is changed, e.g. syscalls, particularly as pertaining to networking
<very-mediocre>
for packages where it's expected, e.g. something that does a lot of IO, it might not mean much, but I'd flinch if for example a networking-related call were added to a library expected to be pure, e.g. math
<ducktype>
to convert []u8 to an asciiz i need to relocate it?
<ducktype>
there is some helper function already in std?
Zaab1t has quit [Ping timeout: 240 seconds]
<ducktype>
i call std.fmt.allocPrint() but i need a zero-terminated string/array to pass in to syscalls
porky11 has quit [Remote host closed the connection]
<ducktype>
i'm not sure which is the best way to do it
very-mediocre has quit [Ping timeout: 256 seconds]
suirad_ has joined #zig
porky11 has joined #zig
<suirad_>
Another way to help with dependencies is enforcing zig fmt on them, which should make strange / obfuscated code more obvious upon review.
<suirad_>
andrewrk: Speaking of security, ive been meaning to try something in zig.
<suirad_>
At comptime you cannot do syscalls correct?
<ducktype>
suirad_: could be possible technically i think but i'm not doing it at compiletime
<ducktype>
suirad_: if you are talking to me :)
<suirad_>
ducktype: I was adding to the previous convo :P
<suirad_>
I was going to see if I could trigger some shellcode at comptime
<ducktype>
suirad_: i see :)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
suirad_ has quit [Ping timeout: 256 seconds]
Zaab1t has joined #zig
steveno has joined #zig
jjido has quit [Quit: going, gone.]
wootehfoot has joined #zig
ducktype has quit [Quit: Page closed]
<andrewrk>
it's not possible to do anything unsafe at compile time
<andrewrk>
the only way to crash the compiler at compile time is via compiler bugs
shollrollah951 has quit [Quit: Leaving]
<rom1504>
can you use all the memory at compile time ?
<andrewrk>
yes
<rom1504>
wouldn't that make the compiler crash ?
<andrewrk>
yes but it is a bug
<andrewrk>
in self-hosted, once some of the zig issues are resolved, we will not have unbounded recursion
<andrewrk>
and so attempting to allocate too much memory during a compilation will give error: not enough memory to complete compilation
<rom1504>
oh ok, cool
<andrewrk>
with potentially more information about why. and this is important because the compiler stays running, providing several features. you don't want it to crash
<rom1504>
how far is zig from being self-hosted now ?
<andrewrk>
pretty far. I think it will happen in 0.5.0 (0.4.0 is the next release)
<rom1504>
ok, keep at it :)
steveno has quit [Ping timeout: 250 seconds]
Zaab1t has quit [Quit: bye bye friends]
jjido has joined #zig
jjido_ has joined #zig
jjido has quit [Read error: No route to host]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
wootehfoot has quit [Read error: Connection reset by peer]