<daurnimator>
andrewrk: re: your comment before about way-cooler; it reminds me of another comment you said once: "zig shouldn't need "bindings" for C libraries" -> do you still think that?
<andrewrk>
yes
<daurnimator>
andrewrk: then how do you e.g. introduce "zig-friendly" APIs to a C library? e.g. so you can pass slices instead of `myfunc(myslice.ptr, myslice.len)` every time?
<andrewrk>
don't do it. just pass myslice.ptr, myslice.len every time
<andrewrk>
use the C types; call the C functions; allow that part of your codebase to be more C flavored
<shritesh_>
I've been wanting to know this: what am I really passing when a function takes in a slice? Is it similar to passing .ptr and .len under the hood?
<daurnimator>
what about when a C library takes a more advanced interface? e.g. C libraries that have a: `mylib_set_alloc(realloc_like_function)` that I need to pass a zig allocator for?
<andrewrk>
shritesh_, currently it's exactly the same as passing a struct { ptr: *T, len: usize }
<andrewrk>
daurnimator, can you spell out the problem for me here?
<daurnimator>
andrewrk: shritesh_: I've been wondering if we can make that compatible with the target system's `iovec` somehow.... alternatively I have this proposal https://github.com/ziglang/zig/issues/2255
<daurnimator>
andrewrk: e.g. I was looking into making the lua C library easy to use from zig: using @cImport on the lua headers, the function definitions you get are all.... annoying to use from zig -> they can be made much nicer by wrapping functions to take a slice; or wrapping them to take an *Allocator... but it goes further: the lua C API defines `luaCFunction = fn ([*c]lua_State) c_int` : and you need to write
<daurnimator>
functions with that signature. but it's much nicer if you have a non-C pointer; as it really can't be NULL.
<daurnimator>
furthermore: C namespacing is a little awkward from zig: `C.lua_pushinteger(L, 42)` instead of what could be: `L.pushinteger(42)`
<daurnimator>
-> it means that C libraries are never as nice to use as native zig libraries
<andrewrk>
daurnimator, I have considered doing something with recognizing C prefixes as namespaces, but haven't come up with anything to propose yet
<daurnimator>
andrewrk: I think there is a proposal around that allows "adding" methods to a struct to create a new struct?
<andrewrk>
I was thinking along the lines of "chopping off" a common prefix and separating into namespaces
<daurnimator>
andrewrk: so I could do: const C = @cImport(...); pub lua = struct { use C.lua_State; pub const pushinteger = C.lua_pushinteger, ..... }
<andrewrk>
e.g. in the @cImport expression you could do something like @declareCNamespace(lua, "lua_");
<daurnimator>
but then also add in a few "zig-friendly" apis: pub fn pushslice(self: *Self, slice: []const u8) c_void { return self.pushlstring(slice.ptr, slice.len); }
<andrewrk>
then it would be something like const c = @cImport(...); c.lua.pushinteger(foo);
<andrewrk>
and of course you could do cont lua = c.lua;
<daurnimator>
andrewrk: that would be helpful; but still not "zig-native" level. e.g. still no methods on structs/struct pointers.
<andrewrk>
I'm not convinced that adding methods to third party types is needed. What benefits does it provide?
<daurnimator>
If I was writing the library in zig; that's how I would have exposed it.... to be unable to do that with 3rd party APIs, makes them inferior.
<andrewrk>
inferior to libraries written in zig?
<daurnimator>
yes
<andrewrk>
doesn't that make a lot of sense? I mean C libraries should be inferior to zig libraries in exactly all the ways that zig is a better language than C
<daurnimator>
not really
<daurnimator>
it's only inferior *in zig*
<daurnimator>
and the fact that it *can* be solved with some thin bindings suggests that it *should*
<andrewrk>
C doesn't have methods either
<hryx>
can = should?
<andrewrk>
I think that someone who is familiar with using a given C library should be able to look at Zig code and it should look familiar in the same way
<andrewrk>
I'll augment that earlier proposal I hinted at though - I could conceive of a way to associate a prefix with a type.
<daurnimator>
andrewrk: that might work....
<daurnimator>
andrewrk: related to struct extension? struct { use C.myprefix; pub fn moremethods() void {} }
<andrewrk>
daurnimator, I'll type up my proposal tomorrow
<daurnimator>
k
<daurnimator>
I need to type up my reply on "consistent methods across containers"
<daurnimator>
swap you ;)
<andrewrk>
I need to switching things up today and write some code before I get grumpy :)
<daurnimator>
(which is to say: trade you replys tomorrow)
<andrewrk>
daurnimator, oh yeah, one thing to note would be to explain why it's meaningful to have the names be the same even when the fn prototypes don't match. e.g. LinkedList remove takes a pointer; ArrayList takes an index
<daurnimator>
mmm. interesting; I didn't think of that. I think my answer is something along the lines of "the parameter is what the iterator gives". but will look tonight
shritesh_ has quit [Quit: Segmentation Fault]
hio has quit [Quit: Connection closed for inactivity]
shritesh has joined #zig
adrusi_ has joined #zig
adrusi has quit [Ping timeout: 250 seconds]
<shritesh>
andrewrk: A major pain point wasm/wasi will soon experience is not having a memory allocator that actually frees.
<shritesh>
(in Zig) :D
<shritesh>
I've been looking into Rust's wee_alloc and I know you're working on the GeneralPurposeAllocator
jevinskie has joined #zig
<daurnimator>
shritesh: should be same in theory as an sbrk-based allocator
<daurnimator>
shritesh: --> can't you just write an sbrk based allocator for all platforms?
<shritesh>
I can't
<daurnimator>
IIRC, sbrk is actually faster than mmap. but inevitably has worse fragmentation problems.
<daurnimator>
shritesh: why not?
<shritesh>
WASM has only memory.grow
<shritesh>
It hands you pages of memory and never takes it back
<daurnimator>
okay.... so?
<shritesh>
I do not want to be the one making the tradeoffs about memory fragmentations
<daurnimator>
WASM doesn't give you the option
<shritesh>
The most I want to do is port wee_alloc (which has made well-defined tradeoffs) to Zig or hope someone else writes an allocator that does so
<andrewrk>
the "small objects" part of GeneralPurposeDebugAllocator is probably a fine idea for sbrk based APIs
<andrewrk>
it's just the "large objects" part that needs to be reworked
<andrewrk>
the small objects thing has no fragmentation but does have predictable fixed overhead
<andrewrk>
which depending on how you define fragmentation maybe you would say is the same thing as fragmentation
<daurnimator>
IMO the best path is probably via a proper arena allocator that supports freeing and has a 'parent' allocator
<daurnimator>
then you can back your 'arena' allocator with sbrk/wasmmemory.grow
<andrewrk>
that'll just be this "sbrk api" allocator backed by std.heap.FixedBufferAllocator or std.heap.ArenaAllocator
return0e has joined #zig
<daurnimator>
andrewrk: IIRC our "ArenaAllocator" doesn't actually support freeing? it's just a "arena-at-once" free?
<andrewrk>
right. use that as backing allocator for "sbrk api" allocator and you have yourself an allocator that supports freeing, can grow, and can be all freed at once
return0e_ has quit [Ping timeout: 258 seconds]
return0e_ has joined #zig
<daurnimator>
andrewrk: right. I was saying there is a global "direct sbrk" allocator. and then have an ArenaAllocator backed by that. which could be the "global sbrk arena allocator" or something
return0e has quit [Ping timeout: 244 seconds]
<andrewrk>
I wonder if std.mem.Allocator should be a union(enum) with possible tags sbrk, mmap
<daurnimator>
I don't think so. why would you need that?
<andrewrk>
yeah that's the wrong layer for that distinction
<andrewrk>
it's an implementation detail, not an interface
<andrewrk>
it's the end of the day. I'm not smart again until I go to sleep and wake up :)
<daurnimator>
and there's lots of implementation details for different allocators... page size allocations? protection mode? on a particular device (e.g. video ram)? backed from a particular file? DAX?
<daurnimator>
I don't think you could hope to enumerate them
<shritesh>
Alright. I'll bring this up when I hit the issue again. Firefox was complaining that "this tab is using a lot of memory" running the formatter yesterday but I haven't encountered it again.
<andrewrk>
the endgame for this is that wanting to use extra memory will be a user permission for web sites
<shritesh>
Yeah. But we do need to have an allocator that actually frees too.
<daurnimator>
shritesh: have a go at it?
<daurnimator>
shritesh: I'd probably read through libarena's pool.c and reimplement the same concept in zig.
<hryx>
andrewrk: Question for you. I'm close to opening a PR for recursive parser. It would be easy to just remove shebang support now -- but would you prefer it be in a separate PR?
<andrewrk>
hryx, go for it now
<hryx>
roger, thanks
<shritesh>
daurnimator: I want to work on a WASM interpreter and WASI execution environment instead :)
<andrewrk>
shritesh, for sure - that's definitely planned. and don't worry you can focus on what interests you - there will be plenty of people who are interested to do the allocator internals stuff
<andrewrk>
I have to resist the urge to start working on a wasi interpreter... I really should prioritize the language changes that nobody else can really do
<daurnimator>
andrewrk: yes please :) coroutine stuff can only really come from you
<daurnimator>
do we have a CIRCLEQ equivalent in zig?
<shritesh>
andrewrk: I have a half-finished PR to implement environment variables, which is the last WASI-specific API right now. The rest are all (almost) POSIX compatible. I think I can get them all done this week. I intend to work on the interpreter starting next week.
<andrewrk>
shritesh, exciting!
<andrewrk>
daurnimator, the thing where you map the same memory consecutively to create a ring buffer with only 1 memcpy required for writes/reads?
<daurnimator>
andrewrk: no. it's a linkedlist with no end. see 'man circleq_entry'
<shritesh>
I'll finish the WASM docs and try to get us listed in wasi.dev too
<andrewrk>
shritesh, nice, that'll be some good outreach
<shritesh>
That's the goal. bketelsen showed me something exciting he's making happen on the browser side of things too
<daurnimator>
I wonder if std.LinkedList needs to be a union of: list, tailqueue, circularqueue
<daurnimator>
andrewrk: ^
<andrewrk>
that's for sure something I'm going to have to consider in the morning and not the evening
<daurnimator>
k
<andrewrk>
emekankurumeh[m], thanks for taking over the sublime-language repo! super helpful
<emekankurumeh[m]>
no problem
scientes has quit [Ping timeout: 246 seconds]
<daurnimator>
left an issue about it so we don't forget.
<andrewrk>
thanks
scientes has joined #zig
<daurnimator>
If you mark it as accepted I'm happy to write a PR.
<hryx>
andrewrk: if you want to reproduce it I need to push my last change
<hryx>
one sec
<andrewrk>
hryx, you're looking for help troubleshooting?
<hryx>
andrewrk: It's not blocking me per se, just wanted to let you know in case it's a new bug
<hryx>
no need to help troubleshoot at this moment
<hryx>
(just pushed the change to my branch BTW)
<hryx>
Er, forgot to metnion, if you want to reproduce it, you'll need to comment out the shebang test, and then run zig test on parser_test.zig
<hryx>
anyway no rush
<andrewrk>
I'm confused - it's not a problem with master branch?
<hryx>
I haven't seen that while running zig test parser_test.zig on master
<hryx>
I should clarify -- I haven't run it on the most recent master, but it does not segfault with the original stage2 parser
marmotini_ has joined #zig
<andrewrk>
ohhh, I see. It's in render, not parse
<hryx>
Yep~
<hryx>
it crashes on a `switch (base.id)`, very spoopy
<andrewrk>
double check that the id of AST nodes agree with the allocated types
<andrewrk>
that's an area of unsafety
<hryx>
oh shoot, good idea. Ok I'll check and let you know
<andrewrk>
I've been thinking lately about how to make Debug and ReleaseSafe modes of Zig actually safe - at least as much as possible. A tradeoff of increasing runtime size for these modes in exchange for safety
<andrewrk>
I think this could make Zig compete more strongly with Rust
<andrewrk>
if we can achieve both simplicity and safety
<andrewrk>
rather than an `unsafe` keyword, zig has the "assume the code in this scope has no bugs" builtin function
<hryx>
That bug (fixed by tyler569) was causing much strife for me. I've gotten way too used to Go's memory safety, heh
<andrewrk>
that's the main issue that I've been thinking about how to solve. use-after-free for stack variables. I think I'm on to something
<hryx>
music to my ears :D
<andrewrk>
it's quite elegant if you think about it: require the programmer to adhere to the premise that stack variables are no longer accessible after the function returns. but it's a lie. the compiler actually does escape analysis in safe modes and allocates escaping stack variables on the heap
<andrewrk>
when the function returns, mark the escaped variables as dead, but keep the memory mapped, with metadata so that loads/stores can be checked
<daurnimator>
e.g. what if I was using @intToPtr() to create a XOR linked list?
<andrewrk>
it's kinda like a garbage collector (as in go) but it doesn't have to do any of that computationally expensive stuff. all it has to do is crash if you use something after it's dead
<hryx>
holy moly, GC in debug mode and not in release mode?
<hryx>
now you are cooking with portals
<andrewrk>
daurnimator, if loads/stores are going to be potentially checked, there will be false positive safety checks. meaning technically unnecessary but harmless
<daurnimator>
andrewrk: and false negatives too...
<andrewrk>
how?
<daurnimator>
andrewrk: wait.... checked against what?
<daurnimator>
a table of all known addresses?
<tyler569>
how would that interact with embedded stuff? (re: beefing up the runtime for more safety)
<andrewrk>
tyler569, it simply wouldn't be available
<andrewrk>
or maybe embedded stuff could opt in, if it could fulfill the necessary API (similar to how the panic function can be supplied)
<tyler569>
mmm *nods*
<hryx>
interesting, makes me curious of the relationship of Debug to embedded platforms overall
<tyler569>
long as you're not disabling debug more in my os ^.^
<tyler569>
mode*
<hryx>
haha
<andrewrk>
it would be the first runtime safety check feature that depends on os-specific features
<daurnimator>
andrewrk: like userfaultfd?
<andrewrk>
I'll have to look up what that is
<andrewrk>
tyler569, right of course debug mode would be available - I mean that this safety feature wouldn't be enabled, similar to how error return trances are disabled for the WASI target
<andrewrk>
*traces. my musical tastes are showing
<tyler569>
haha yeah, sounds like the perfect way to handle it
<hryx>
I took you for more of a technical metalcore type
<hryx>
daurnimator: my god, it's....... full of The Simpsons
qazo has quit [Read error: Connection reset by peer]
<andrewrk>
I'm friends with the security/crypto guy on the Go team, and he made a good point. People *will* incorrectly choose ReleaseFast mode when ReleaseSafe is the correct option for them
<daurnimator>
andrewrk: rename it from ReleaseFast to ReleaseUnsafe?
<andrewrk>
he suggested ReleaseUnsafe, and while I agree that does solve the problem, it's not quite a description of what the mode is optimizing for
<andrewrk>
nice daurnimator :)
<daurnimator>
I'm actually not sure what the difference between Debug and ReleaseSafe is....
<hryx>
is that Filippo by any chance? :>
<andrewrk>
hryx, yep
<andrewrk>
I have a huge amount of respect for him
<hryx>
a very smart and charismatic person to be sure!
<emekankurumeh[m]>
if a pointer is being returned, what about just checking if the pointer points to somewhere in the stack frame>
<emekankurumeh[m]>
*?
<hryx>
andrewrk: gut check, on the topic of build modes, what did you think about renaming Debug to Development?
<daurnimator>
andrewrk: can those 5 points in the build mode table be decomposed?
<andrewrk>
emekankurumeh[m], good question - the problem is that the range of the stack keeps changing. Plus, even if a function returns, maybe another function is called, with the same size stack frame! you can't tell the difference
<hryx>
just thinking about how names imply "how you are supposed to use it"
<daurnimator>
e.g. -Os vs -O2 vs -O3. -g, --unsafe?
<emekankurumeh[m]>
so the aba problem then?
<daurnimator>
andrewrk: FWIW I think the most important "safety" thing we need is the "nocopy"/"fixed" annotation. seems to be the most common mistake in zig.
<andrewrk>
hryx, ah, yes I'm still thinking about that. one thing to consider is, say, if your main build mode is ReleaseFast, and then you want to troubleshoot a problem in one particular area so you use @optimizeFor(.Development). It would be weird to ship that to production, even though that's exactly what you want to do
<emekankurumeh[m]>
or somewhat similar to it
<shachaf>
You can maybe look for values past the current stack frame after return, conservative-GC-style.
<andrewrk>
daurnimator, definitely agree. I'm planning on getting through this round of PR feedback, and then getting started on that
<hryx>
ahh right, I gotta go back and read the @optimizeFor proposal to get a better understanding
<andrewrk>
shachaf, that would work if we had a complete list of live references. but a user could, for example, @ptrToInt, display a message box to the user and have them memorize the address, sleep for 1 second, and then prompt the user to put the address back in the message box, and then try to dereference it
<andrewrk>
that was convoluted to be funny. point being we don't have a complete list of live references
<shachaf>
Well, dereferencing user-provided inputs is the problem there.
<daurnimator>
shachaf: not really
<andrewrk>
but I think we can still accomplish safety for that scenario
<shachaf>
But it's true that a conservative GC style of thing can't be perfect anyway if you use tricks like that.
<daurnimator>
shachaf: pointers can come across the network (see: CRIU). and you never know if you're talking to a machine or a human over a network connection.
<andrewrk>
emekankurumeh[m], that's an interesting way to put it, but yeah I think that's right
<shachaf>
But you're not going to have a static check that a memory address you get over the network is a valid pointer.
<andrewrk>
that's right, not static. the situation under discussion are the "safe" build modes which are allowed to have runtime safety checks
<shachaf>
I should read more of the text before commenting.
<andrewrk>
the thing zig brings to the table here is that all code is written under the assumption - and is checked to be correct - that it works with strict premises. for example stack variables end their lives when the function returns. so while safe modes might not be fast, the safety they provide, when disabled, *does* allow for the bottlenecks of code to go *very fast*
<andrewrk>
that's the idea anyway. I think it's definitely worth pursuing. if it works well, it eats both rust and go's lunch
<andrewrk>
om nom nom nom
<hryx>
:pacman:
<andrewrk>
unrelated: as soon as I start getting pull requests to src-self-hosted/translate_c.zig instead of src/translate_c.cpp, I'm going to stop working on https://github.com/ziglang/zig/issues/1964 and move on to other stuff
<hryx>
andrewrk: do you foresee assigning an owner to big chonker issues like #1964? or just whoever will contribute this and that, as the commits come
scientes has quit [Ping timeout: 245 seconds]
<andrewrk>
I think that 1964 in particular is situated quite well for piecemeal work
<andrewrk>
I've done that on purpose - currently `zig translate-c` and @cImport will use the C++ implementation, and `zig translate-c-2` will use the .zig implementation
<andrewrk>
at some point I'll delete the C++ implementation and throw a party
<hryx>
haha
<hryx>
the "contributor friendly" tag was smart, helps with discoverability, IMO
<andrewrk>
ok so address 1. that seems pretty likely that code somewhere else overwrote it
<andrewrk>
whereever the pointer was stored
<hryx>
ah yeah. plz hold while I get my sherlock holmes hat and pipe
<hryx>
(actually, I must run an errand. AFK for 15 mins)
<andrewrk>
hryx, ooh I have a good idea
<andrewrk>
when you get back. (gdb) watch *0x1
<andrewrk>
hmm no that will break at the same point you're already getting the segfault.
<tyler569>
you mean watch base, right?
<tyler569>
yeah that
<andrewrk>
I've seen a demo of using "undo" in gdb but I've never gotten it to work personally
<hryx>
I've just added @breakpoint() before the bad dereference, and then run gdb, but it has skipped the breakpoint. What'm I missing?
<andrewrk>
are you sure the @breakpoint() is in the correct place? it might mean the bad dereference is elsewhere\
<daurnimator>
andrewrk: seen 'rr'?
<hryx>
Hmm, I think it's in the right place. Actually tyler and I saw something while coworking on zig a couple weeks ago. @breakpoint might be having issues. I will attempt to create a minimal reproduction!
<hryx>
unless I misunderstood how to use @breakpoint. definitely possible
jjido has joined #zig
<hryx>
Huh, @breakpoint works perfectly well on master. I would love to figure out what changed, but it might be better if I simply rebase upon master and move on
marmotini_ has quit [Ping timeout: 244 seconds]
_whitelogger has joined #zig
ltriant has quit [Quit: leaving]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
_whitelogger has joined #zig
_whitelogger has joined #zig
_whitelogger has joined #zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
marmotini_ has joined #zig
marmotini has quit [Ping timeout: 244 seconds]
very-mediocre has joined #zig
scientes has joined #zig
<tgschultz>
andrewrk: if I understand correctly, this saftey idea your talking about breaks one of zig's fundamental concepts and does a hidden heap allocation?
<scientes>
tgschultz, llvm is working towards these type of features
<scientes>
non-integer pointers, and mill cpu will have hardware support for garbage collection
<scientes>
> Non-integral pointer types represent pointers that have an unspecified bitwise representation; that is, the integral representation may be target dependent or unstable (not backed by a fixed integer).
<scientes>
on mill cpu if you use 60-bit pointers you can still treat them as integers, but you loose the garbage collection features
<tgschultz>
shouldn't we care more about hardware that actually exists? Ugh. I'm just really annoyed by this obsession with saftey to the point of basically having a garbage collector in every debug build.
<hryx>
@tgschultz maybe it's ok to break this rule in devopmenntn
<hryx>
*development mode?
<scientes>
i like that the language is still allowing you to do what you want, generally
<tgschultz>
technically every turing complete language does
<scientes>
like i had to use pointers instead of a value in C++ recently because of C++'s object model wouldn't allow me to use undef values
<scientes>
it was really annoying
<scientes>
tgschultz, performantly as well
<scientes>
zig, like c, if you know what the hardware will do, you can generally tell the language to do that, AND it will be portable
<tgschultz>
except in your debug build where now it will be doing hidden allocations (which can OOM!)
<tgschultz>
I prefer things I can reason about
<scientes>
tgschultz, it will probably be too slow as well
<scientes>
tgschultz, actually it doesn't have to, if it is implemented as a bit-map
<scientes>
then you just use 1/64th or 1/32th of the memory in addition
<scientes>
anyways, first time i'm hearing about this feature
<scientes>
tgschultz, yeah hidden allocations break other safety stuff, like debuggin rt applications
<scientes>
and you can never be perfectly safe----I find when language ppl talk about "safe" they are kinda arrogant
<scientes>
go's split stacks is a huge performance bottleneck
shritesh has quit [Quit: Segmentation Fault]
<scientes>
andrewrk, how does this differ from address sanitizer?
knebulae has quit [Read error: Connection reset by peer]
shritesh has joined #zig
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
marmotini_ has quit [Remote host closed the connection]
halosghost has joined #zig
hio has quit [Quit: Connection closed for inactivity]
return0e_ has quit [Ping timeout: 258 seconds]
Ichorio has joined #zig
Ichorio_ has joined #zig
Ichorio has quit [Remote host closed the connection]
hio has joined #zig
wilsonk has joined #zig
wilsonk|2 has quit [Ping timeout: 255 seconds]
Ichorio_ has quit [Quit: Leaving]
<andrewrk>
tgschultz, that's correct about the hidden heap allocation
<andrewrk>
it would still have to reserve stack space for the variable, in case the hidden heap allocation failed
<andrewrk>
and note that it doesn't require nearly as much baggage as a garbage collector. for example there is no "stop the world" thing and no "mark and sweep" thing
<andrewrk>
it's just putting the memory somewhere else so that safety checks can be possible
<andrewrk>
scientes, you tell me. I don't know how the address sanitizer works
<scientes>
Static linking of executables is not supported.
wootehfoot has joined #zig
<tgschultz>
andrewrk, is it possible to hijack the call trace of an @compileError? I have a recursively built type (comptime pseudo-struct) so the trace is the same line about a dozen times.
<andrewrk>
tgschultz, e.g. the limit of 10 isn't showing you where the problem is?
<andrewrk>
I'm not sure what you're asking
<tgschultz>
right, because recursion. however in this case I do know where the problem is because I created it to test the compileError, I'm just wondering if I can cleanup the output.
<andrewrk>
ah
<tgschultz>
Actually, I'm probably better off impleneting that myself. But if there's a way, I am still curious.
<andrewrk>
hmmm. can you open an issue for this? I think this is worth thinking about but I don't have a good answer right now
<andrewrk>
it's related to, when capturing a stack trace at runtime, how it's common to pass around the "first" return address
<andrewrk>
scientes, there is one thing I can tell you about how it would be different - clang's sanitizers are all incompatible with each other and can't be enabled together
scientes has quit [Ping timeout: 244 seconds]
<tgschultz>
alright, I'll open an issue. strangely it turns out I can't clean this up the way I thought I could.
wootehfoot has quit [Quit: Leaving]
wootehfoot has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
<andrewrk>
thanks tgschultz
<tgschultz>
it occurs that one could use an output filter that checked if the previous message was the same as the one being emitted, kept a count, and then just wrote something like "(repeated N times)"
<tgschultz>
condenses the output yet keeps the recusion level information
<andrewrk>
I like that idea
<andrewrk>
potentially it would detect cycles as well, but that's a lot more complicated
qazo has joined #zig
meheleventyone has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<donpdonp>
whats the zig way to turn a regular string into a cstring? i know there is the c"literal" but I want to start with a string, using it in the regular zig ways, and convert it to a cString at the last minute
<andrewrk>
donpdonp, how long does it have to live?
<andrewrk>
just the stack frame?
<donpdonp>
yes
<andrewrk>
is the upper bound length known at compile time?
<donpdonp>
i thought there was a @addNullBytetoString() thing at one point :)
<donpdonp>
andrewrk: yes
<donpdonp>
var url="http:/blah"; c.doit(url.c_str) essentially
<donpdonp>
i suppose []u8.c_str is not as simple as I would like given it has to allocate an extra byte and that throws everything off.
* donpdonp
shakes fist at the constraints of memory management
<andrewrk>
donpdonp, that's one reason string literals are planned to include the null. they'll be more versatile
<andrewrk>
along with pointer type that annotates that there is an extra null byte at the end
<donpdonp>
nod.
<donpdonp>
hmm im still confused as to how pub fn toPosixPath(file_path: []const u8) ![posix.PATH_MAX]u8 helps. im trying (esentially) c.doit(toPosixPath("/path")) and im getting expected type '[*c]const u8', found '[256]u8'
<donpdonp>
if I still have to cast the result, wouldnt a function of return str ++ "\x0"; work as well, where the caller would take the return_value.ptr ?
<andrewrk>
donpdonp, you'll have to assign the result to a variable, then take the address of the variable
<donpdonp>
const cStr = sliceToCstr("someurl", 255); c.doit(&cStr); => expected type '[*c]const u8', found '*const [256]u8'
<donpdonp>
ignore that 255 param, the function signature is pub fn sliceToCstr(str: []const u8, max: u32) [256]u8
<donpdonp>
this is also weird, looking at array append with var str_null = str ++ "\x0"; and get error: newline not allowed in string literal
<andrewrk>
donpdonp, that's a bug, it should allow that cast
<andrewrk>
someone ran into that yesterday too
<andrewrk>
"error: newline not allowed in string literal" means you forgot the ending "
<donpdonp>
i would agree with that but the ending quote is there
<donpdonp>
tootdeck/zig/src/ipc.zig:23:31: error: newline not allowed in string literal
<donpdonp>
var str_null = str ++ "\x0";
<donpdonp>
^
<donpdonp>
ah \x wants 2 digits. \x00
<andrewrk>
ah. the error should have been "error: '"' is not a hex digit"
<donpdonp>
heh. ok.
jjido has joined #zig
<donpdonp>
here's an oddity. im using var newMem = try allocator.alloc(type, size); with success, but just now im using the same form "var str_null = try allocator.alloc(u8, str.len+1);" => error: expected type '[*]u8', found '@typeOf(std.mem.Allocator.alloc).ReturnType.ErrorSet'
<andrewrk>
looks like the code forgot to unwrap the error somewhere
<donpdonp>
hmm perhaps im not understanding var x = try funcErrorUnion(); versus var x = try funcErrorUnion() catch unreachable;
<andrewrk>
both of those unwrap the error, and x will have the value
<andrewrk>
oh
<andrewrk>
don't put both try and catch
<donpdonp>
whoops, type on my part
<donpdonp>
typo on my part, its not actually there
<donpdonp>
var x = func() catch unreachable; works as expected. im puzzled by the error for var x = try func(); especially since im using it in other places of the codebase
<donpdonp>
i get that x will be initialized as either an error or the result type, but the compiler error seems to be saying the value is always the Allocator ErrorSet.
<donpdonp>
error: expected type '[*]u8', found '@typeOf(std.mem.Allocator.alloc).ReturnType.ErrorSet'
<donpdonp>
var str_null = try allocator.alloc(u8, str.len+1);
<tgschultz>
does the function that is called in return an error union? try is equivelent to `var str_null allocator.allc(u8, str.len+1) catch |err| return err;`
<tgschultz>
normally using `try` in a function that doesn't return an error union gives a meaningful error, but maybe that was broken recently?
<donpdonp>
tgschultz: ah that was it. at some point I took ! off the return value.
<donpdonp>
as far as the enclosing function.
<donpdonp>
try allocator.alloc(u8, str.len+1); itself hasnt changed since its a std lib
<tgschultz>
right
<tgschultz>
andrewrk: shouldnt `[N]u8` implicitly cast to `[*c]const u8`even without storing it in a variable and taking a pointer? since [N]u8 casts to []const u8, IIRC.
<donpdonp>
tgschultz: andrewrk | donpdonp, that's a bug, it should allow that cast. someone ran into that yesterday too
<andrewrk>
*[N]u8 should. but that other cast you pointed out is planned to be removed with the new string literal type
<andrewrk>
new string literal type will be a pointer, not an array
<donpdonp>
wouldnt a ptr loose the length value? an array makes sense to me.
<tgschultz>
it's a pointer to an array
<tgschultz>
so the length is part of the pointer's type information
marmotini_ has joined #zig
SimonNa has quit [Remote host closed the connection]
SimonNa has joined #zig
Sahnvour has joined #zig
scientes has joined #zig
halosghost has quit [Quit: WeeChat 2.4]
<mikdusan>
andrewrk: `ci/azure/macos_script` re: using gcc-8 from homebrew. is it still goal to link zig without runtime dep /usr/lib/libc++.dylib ?
<mikdusan>
libc++ could be added to "llvm+clang" and while that increases time/complexity to build llvm, i think it's worth it if it means Xcode can be used instead of gcc8
return0e has joined #zig
marmotini_ has quit [Ping timeout: 255 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shritesh>
How would I represent / iterate over null-terminated array of pointers?
<scientes>
they must be optional pointers
<shritesh>
I'm currently representing it as []?[*]u8 and it seems does represent the null pointers as null. I expected `for (pointers) |ptr|` to stop at the null but it doesn't.
<shritesh>
*it seems that it does
<scientes>
shritesh, "it seems does represent the null pointers as null" that is guaranteed by the language spec
<scientes>
for pointers
<scientes>
but non-optional ones have llvm's "nonnull" attribute
<shritesh>
Ah. So I'd have to do an if inside the for?