<daurnimator>
apparently other people didn't like it.... 2 thumbs down 0 thumbs up :(
<hryx>
daurnimator: is the controversy that it introduces runtime length calculation?
<hryx>
the .len thing
<daurnimator>
maybe?
<hryx>
it does raise some concern just because of the idea that "only things that look like functions invoke functions". if it were .len() it might feel less out of character
<daurnimator>
I don't see it as that different to e.g. passing a struct by value invoking memcpy
<hryx>
that's a reasonable argument
<emekankurumeh[m]>
does .len work on [*] pointers?
<daurnimator>
emekankurumeh[m]: no. the length of those is unknown
<fengb>
`c"aoeu" is of type [4]null const u8`
<fengb>
I don't particularly like the len == 4 while @sizeOf == 5
<scientes>
wait, we have null types now?
<daurnimator>
scientes: no. we're discussing the proposal
<scientes>
oh ok, for a moment there I was pretty excited...
<fengb>
But I'm not sure what the alternative would be. It'd be awkward that slicing `[N]null const u8` gives you an extra null character
<daurnimator>
fengb: huh?
<scientes>
yeah I think it should have a length
<fengb>
`c"foo"[0..] => "foo\0"` would be weird
<scientes>
but maybe some way to avoid getting that length stack allocated
<daurnimator>
btw, we have other situations where @sizeOf isn't what you may naively expect: e.g. hidden tag on unions.
<scientes>
but what if you set a byte inside it to null, what is the length then?
<fengb>
Or would it? I'm assuming transparent interop but maybe there should be some friction
<scientes>
^^^
<daurnimator>
scientes: part my proposal (linked above) is that everytime you fetch .len it does `strlen`.
<scientes>
but then it shouldn't have a length
<scientes>
if that is your definition
<scientes>
just just need to make actual strlen() marked pure
<scientes>
well that wouldn't be sufficient
<scientes>
because its a pointer, so you can't mark it const
<daurnimator>
scientes: please read the proposal before debating it....
<scientes>
sorry...
return0e has quit [Ping timeout: 248 seconds]
<scientes>
It is valid to read [N]null T at N. You are guaranteed to get null.
<scientes>
or rather "it is undefined behavior to not have null there"
kristoff_it has joined #zig
<scientes>
so can you assign to len, and if so does it insert a null?, and does it change the type too?
<daurnimator>
scientes: no. you cannot assign to len.... in any slice/array type in zig
<scientes>
and can you assign a smaller to a larger at a specific index, i.e. [10]null T, [5]null T, a[2] = b
<scientes>
oh you have to re-slice yes of course
<scientes>
[]null T can be 'cast' to []T via nullslice[0..nullslice.len]. The .len here is invoking a strlen-like operation.
<scientes>
and so if you write to in a null it would change the type
<daurnimator>
scientes: ?
kristoff_it has quit [Ping timeout: 245 seconds]
<daurnimator>
scientes: where are you writing?
<scientes>
if you had [5]null T, and did a[3] = 0
<scientes>
then you would suddenly have [2]null T
<scientes>
which is a differn't type
<daurnimator>
scientes: no.
<daurnimator>
scientes: [5] there is the capacity; not the length.
<scientes>
so it implicitely casts to a shorter capacity?
<daurnimator>
no.
<scientes>
why not?
<scientes>
oh of course
<scientes>
you would need a null
<scientes>
how do you specify the capacity when dereferencing a null slice?
<scientes>
or you can't do that, because like in C arrays are really pointers?
<daurnimator>
scientes: ? what do you mean
<scientes>
how do you allocate a null array not on the stack?
<scientes>
oh nvm, that is a dumb question
<scientes>
It is similar to []null T except uses a strnlen-like instead of a strlen-like.
<scientes>
it would use strlen always in release-fast mode
<daurnimator>
scientes: strnlen with a compile-time-known length can be faster than strlen
<scientes>
oh yes
<scientes>
didn't think of that
<daurnimator>
scientes: also note that *most* `[N] null T` would be in the form of compile time constants... which are 1. constant. and 2. compil-time-length-known
<scientes>
Null arrays must always be zero-initialized when they are created
<scientes>
that's the thing I don't think you mentioned in your proposal
<scientes>
there is really no other way to do it
<daurnimator>
the main usecase for non-constant null terminated arrays is the structures returned from `getdents` and unix socket addresses from `getpeername`
<daurnimator>
why would null arrays need to be zero-initialized?
<scientes>
null arrays are really useful in low-memory situations
<scientes>
daurnimator, because you have to set the last element by your own admission, and otherwise then length would be far less useful
<scientes>
they are actually quite useful in certain data strutures
<scientes>
usually containing pointers
<scientes>
where you are already linearly iterating, so a length is pointless
<daurnimator>
scientes: actually due to branch predicition factors its often faster to strlen and then iterate to it anyway :P
<scientes>
but i guess then a pointer is the size of a length
<scientes>
so there is not a good reason against just using a slice there
<scientes>
*a null is the size of a length
<scientes>
sometimes a length is just u32 too, but I don't think zig will ever do that
<daurnimator>
scientes: to expand on the use case above: var ss: sockaddr_storage = undefined; try linux.getpeername(sock, &ss); const mynullslice = ss.sun_path[0..ss.sun_path.len];
<scientes>
but llvm likes to use such things: 32-bit lengths on 64-bit platforms
<scientes>
to save memory
<fengb>
c"" is ~3-7 bytes smaller than "" :P
<scientes>
daurnimator, yes i've used those APIs
<scientes>
fengb, generally 7 these days
<daurnimator>
scientes: note the lack of zero initialisation.... we just rely on the OS to avoid > 2:13:56 <scientes>or rather "it is undefined behavior to not have null there"
<fengb>
I've been doing a lot of wasm so I'm biased towards 32bit
return0e has joined #zig
<daurnimator>
fengb: 64bit wasm is a thing...
<scientes>
daurnimator, that's why you need the zero initialization.....
<daurnimator>
scientes: how would that help (e.g. if the OS decided to get rid of the 0)
<scientes>
but i guess you are at least testing for an error
<fengb>
It's undefined. Only wasm32 is a real spec
<fengb>
Er... finalized*
<daurnimator>
scientes: also that's why .len on an null array uses strnlen
<scientes>
yes
<scientes>
that is nice
<scientes>
and you could even fix up some strage apis that don't terminate
<scientes>
by having an extra byte
<scientes>
but then you have to initialize.....
<scientes>
cause you have to initialize if you want to cast to [*]T
<scientes>
and then use a strlen-like function
<scientes>
yeah I'm not really feeling it
<scientes>
i feel that [*] pointers do most of the job
<scientes>
and we just need to add a strnlen builtin, either to zig or llvm
<daurnimator>
scientes: the important thing is have a type to use with e.g. `open`
<scientes>
llvm would probably be interested in that
<daurnimator>
scientes: so that e.g. you can't pass a non-null-terminated string to open
st4ll1 has quit [Ping timeout: 258 seconds]
<scientes>
yes, your proposal is basically about adding debug safety
<scientes>
for a common use case
<scientes>
but you could only do that if the api accepting had a maximum slice length
<scientes>
cause otherwise the debug checks would potentially search all 64bits of address space
<scientes>
looking for a null
<scientes>
we can use PATH_MAX for that, but your proposal doesn't cover lengths of slices
<scientes>
and that is kinda getting ugly
<scientes>
at the debug checks could themselves segfault
<fengb>
Like all internet flamewars, tabs peeps and spaces peeps just loudly talk over each other
<fengb>
I'd love a point where tabs and character alignment can actually be independent but I haven't seen an editor do that correctly, let alone all of them
<daurnimator>
fengb: I've almost never seen alignment that I agree with
<fengb>
Although... go fmt does it really well so *shrug*
<daurnimator>
fengb: i.e. my answer to "but tabs suck for alignment" is "stop aligning"
<fengb>
Uh... sure. Tell that to everybody else :P
<fengb>
I also wish editors actually display tabs so it's obvious what's happening :/
<daurnimator>
does yours not?
<fengb>
And one thing I'm actually adamant about is "don't mix tabs and spaces"
<fengb>
Mine does yea, but most don't. And people get it wrong all the time
<daurnimator>
I wish it was easier to run linting from CI
<fengb>
Other than that... I like auto formatters and prefer to just adapt whatever is the default
<fengb>
I fought go fmt for about a week before giving up and realizing it's just better to not care >_>
<daurnimator>
I'm glad zig fmt exists..... it's not something you can easily bolt on afterwards
darithorn has quit [Quit: Leaving]
<daurnimator>
Though I'm sad that we don't run it on CI of zig itself....
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
<fengb>
Obviously the solution is configurable widths for spaces :P
<gonz_>
The accessibility argument is a good one and one that I personally hadn't considered.
IntoxicatedHippo has joined #zig
<IntoxicatedHippo>
Is there currently a way to specify the calling convention for a single function (as in __attribute__((ms_abi)) in clang/gcc)?
<IntoxicatedHippo>
How does LLVM handle calling conventions? Perhaps it would be possible to have callconv take a CallingConvention struct which has functions to generate the prologue and epilogue as well as specifying callee-saved registers.
<daurnimator>
that gives me an idea.......
<daurnimator>
andrewrk: what if `asm` blocks returned naked functions?
return0e has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
kristoff_it has joined #zig
marmotini_ has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
marler8997 has quit [Ping timeout: 260 seconds]
fengb has quit [Ping timeout: 260 seconds]
hio has joined #zig
st4ll1 has joined #zig
brakmic has joined #zig
bugabinga has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
marmotini_ has quit [Ping timeout: 268 seconds]
IntoxicatedHippo has quit [Quit: Leaving]
tdc has joined #zig
fubd has joined #zig
Ichorio_ has joined #zig
IntoxicatedHippo has joined #zig
Sahnvour has quit [Quit: WeeChat 2.5]
marmotini_ has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Client Quit]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
st4ll1 has quit [Ping timeout: 272 seconds]
kristoff_it has joined #zig
very-mediocre has joined #zig
nifker has joined #zig
samtebbs has joined #zig
very-mediocre has quit [Remote host closed the connection]
very-mediocre has quit [Remote host closed the connection]
bugabinga has quit [Quit: Connection closed for inactivity]
nifker has quit [Ping timeout: 245 seconds]
marmotini_ has quit [Ping timeout: 272 seconds]
Ichorio_ has quit [Ping timeout: 252 seconds]
<marijnfs__>
andrewrk: planning any live codings soon?
<daurnimator>
marijnfs__: he usually does fridays
<via>
making a barebones freestanding arm zig program that links in libopencm3 was actually easy (coming from someone just starting out with zig)
<via>
need to figure out if zig is outputing hardfloat or not though
tdc has quit [Ping timeout: 246 seconds]
tdc has joined #zig
<via>
does cInclude not do well for static inline'd functions in a header file?
<via>
i spoke too soon, i'm running into a lot of issues with all the headers for libopencm3 when i actually start trying to use them :(
nifker has joined #zig
<via>
https://github.com/via/zig-miniblink -- build gives me "cimport.zig:1402:19: error: use of undeclared identifier 'GPIO_PORT_B_BASE' \n pub const GPIOB = GPIO_PORT_B_BASE;"
<via>
though if i add a #error to the line where GPIO_PORT_B_BASE is installed, i get that error, so i know zig is seeing the line
<samtebbs>
via: I get some libc-related errors when trying to build your project
dimenus has quit [Read error: Connection reset by peer]
<samtebbs>
note: libc headers not available; compilation does not link against libc
<samtebbs>
Seen that before?
<via>
yeah, but only when there's an error, i know there's no libc so that does't seem like it would be a problem
<samtebbs>
I also get cimport.h:2:10: note: 'libopencm3/stm32/memorymap.h' file not found
<via>
re: my earlier static inline funcs, i think the issue is ' warning: TODO handle C GCCAsmStmtClass', so there goes that
<via>
there's a submodule in there for libopencm3
<via>
also, memorymap.h shouldn't need to be directly included, i was just debugging and accidentally left that in there
<via>
i'm guessing libopencm3's preprocessor shenanigans are too extreme for zig to deal with, but in my libopencm3 projects i keep all that interaction to a single c file anyway, so i could just keep that part c
<daurnimator>
via: zig has all of clang, so preprocessor shenanigans aren't a problem unless you want to use macros from zig
fengb has joined #zig
<fengb>
When I use an allocator for a struct, the compiler doesn't tell me things are wrong. Is this a bug?
<fengb>
.slice is uninitialized and pointed at garbage
<via>
daurnimator: then i'm not sure why thats not working
<fengb>
Also, it's not really obvious that struct default values don't run when using an allocator but I'm not sure that can be fixed
brakmic has quit [Remote host closed the connection]
halosghost has joined #zig
<fengb>
via: huh... it works if I manually set "#define GPIO_PORT_B_BASE (0x0400)"
<via>
fengb: where? in the one of the opencm3 headers?
<fengb>
I think it's a limit to how #define is translated
<fengb>
It seems to only work with literals, not expressions
<via>
bummer -- though i'd think if clang were doing all the heavy lifting tere that it wouldn't matter
<via>
i won't be able to directly use libopencm3 until the gcc inline assembly works anyway, so i'll stick to the hardware/libopencm3 interface in c, and the rest of the codebase in zig
<fubd>
the lib that was built with the mangling msvc linker
<fubd>
that
<fubd>
*that's the problem I suppose
<emekankurumeh[m]>
fubd: try a mingw lib
<fubd>
hmm
<andrewrk>
fubd, that's still supposed to work, if your target C ABI is msvc
<fubd>
andrewrk I'm not calling setTarget in my build.zig
<fubd>
what is the default abi in zig build on windows?
<emekankurumeh[m]>
msvc
<andrewrk>
`zig targets` shows you what it thinks is native
<dimenus>
i'll compile glfw on windows and investigate
<fubd>
msvc (native)
<fubd>
yeah
<andrewrk>
I think it's (1) translate-c needs to notice the dllimport attribute and output zig code that has that attribute and (2) zig needs to support the attribute
<andrewrk>
I was originally hoping we could just ignore that stuff and make everything "just work" but my current understanding is that it's a coin flip whether they decided to build with mangled symbols or not, so you are forced to specify whether they did when importing
<andrewrk>
kernel32 stuff, for example, doesn't need dllimport, and in fact things break if you use that
<fubd>
dimenus vcpkg will install the binaries i'm using if you run into trouble
<fubd>
it's also reproducible i'm sure if you just make a one function exporting dll
<fubd>
and then attempt to use it via @cImport
<dimenus>
you're link time loading then?
<dimenus>
not runtime?
<fubd>
yes
<fubd>
link time
<fubd>
lld.exe has an undefined symbol
<fubd>
"glfwInit
<dimenus>
is there a reason you're using lld instead of link?
<emekankurumeh[m]>
benchmarks for mimalloc are going to be added soon
<mikdusan>
my limited experience with mimalloc was not so positive -- felt that it's not very polished; docs say you can use static override but .a never gets built nor is there cmake directives for it
wootehfoot has joined #zig
<mikdusan>
the dynamic override immediately crashes on macos
<mikdusan>
do admit though that I didn't give it more than some tinkering time and after meeting this resistance just moved on.
brakmic_ has joined #zig
brakmic has quit [Ping timeout: 272 seconds]
<mmx87>
To be fair, it's fairly new. I'm sure they improve it. I wasn't aware of rpmalloc.
Flaminator has joined #zig
kristoff_it has joined #zig
<emekankurumeh[m]>
the part i find amusing is that the author works at microsoft
kristoff_it has quit [Ping timeout: 258 seconds]
lunamn_ has joined #zig
lunamn_ has quit [Client Quit]
lunamn has quit [Ping timeout: 268 seconds]
<andrewrk>
damn. might be time to pay off some excessive memory usage debt
fubd has quit [Ping timeout: 260 seconds]
<emekankurumeh[m]>
imo we need to clean up some of the tests
lunamn has joined #zig
<emekankurumeh[m]>
some use S.doTheThing and other have external functions
<andrewrk>
feel free to do that, as long as the tests continue to cover the thing they're trying to cover
<andrewrk>
tgschultz, @unionInit is merged
jjido has joined #zig
<emekankurumeh[m]>
should i use S.doTheTest?
<andrewrk>
emekankurumeh[m], btw #2799 looks pretty good, if you add a test
<andrewrk>
I'd like to try to get your other PRs merged
<andrewrk>
let me know if anything is blocking you
ManDeJan has quit [Ping timeout: 248 seconds]
<emekankurumeh[m]>
i just added a compiler error test and i'm adding a behavioral test right now
<emekankurumeh[m]>
i think i might also put a note in the langref
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
bheads has quit [Ping timeout: 245 seconds]
<andrewrk>
emekankurumeh[m]: in answer to your question, I prefer the namespaced tests (S.doTheTest) but there should be one test to cover calling functions outside of the test scope
<emekankurumeh[m]>
so both?
<andrewrk>
All behavior tests can namespace, except 1 which is testing calling a function from the scope of the current file
bheads has joined #zig
return0e_ has quit [Ping timeout: 258 seconds]
<emekankurumeh[m]>
i see what you mean
<andrewrk>
Please be real careful. It would be a shame to lose test coverage without realizing it
<andrewrk>
Personally I don't mind the inconsistency; I don't think it causes problems in practice
<emekankurumeh[m]>
i don't really mind either, it just confused me a bit when i was adding a test
return0e has joined #zig
return0e_ has joined #zig
fubd has joined #zig
return0e has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
dimenus has quit [Ping timeout: 272 seconds]
kristoff_it has quit [Ping timeout: 246 seconds]
fengb has joined #zig
<fengb>
andrewrk: are there supposed to be guards against uninitialized structs from allocators?
<andrewrk>
reading undefined and even doing operations on undefined makes sense sometimes
daurnimator has quit [Ping timeout: 252 seconds]
<andrewrk>
operations which have no possible side effects operating on undefined result in undefined; provided the value is never branched on, everything is fine
wilsonk has quit [Ping timeout: 246 seconds]
kristoff_it has quit [Ping timeout: 248 seconds]
wilsonk has joined #zig
brakmic has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic_ has quit [Ping timeout: 245 seconds]
brakmic has joined #zig
<andrewrk>
nice, after timonkruiper's PR, on Linux, `zig build-exe ../example/hello_world/hello.zig --release-small --strip --single-threaded` yields a 9.8KB executable, and stripping debug info with `strip` (zig's --strip feature isn't complete yet) takes it down to 6.0KB
<andrewrk>
that's still initializing TLS, which could potentially be avoided in some cases
<andrewrk>
FireFox317, do you have a twitter handle? I'm going to brag about how small binaries can be now
samtebbs has joined #zig
<FireFox317>
Nope, maybe you could name my github username :)
return0e has joined #zig
wilsonk has quit [Ping timeout: 246 seconds]
<darithorn>
did error handling change recently?
<darithorn>
if I have a function that can throw an error. I can simply "ignore" the error by assigning to a variable. Is that intentional?
<emekankurumeh[m]>
if the variable is not `_` then it should be fine
<darithorn>
okay. has it always been that way?
<darithorn>
i guess i've been a good boy and always handled my errors and never noticed lol
return0e_ has quit [Ping timeout: 245 seconds]
<mikdusan>
andrewrk: just fyi your github sponser button complains of .yml errors
<fengb>
It complains because he's not actually sponsored :P
<emekankurumeh[m]>
yes, errors can be stored in variables
<mikdusan>
that's a silly error ;)
<andrewrk>
I hope GitHub "fixes" the "error" soon
<fengb>
"Some users provided are not enrolled in GitHub Sponsors. Apply to the beta."
<emekankurumeh[m]>
they should just go ahead and fix
<fengb>
They should fix it by turning it into a promote link
<fengb>
Although that could be pretty abusable
wootehfoot has quit [Read error: Connection reset by peer]
wilsonk has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
<andrewrk>
darithorn, that's a known thing. but there's a planned compile error for if you never use a variable
<darithorn>
okay that's good to know
fengb has quit [Ping timeout: 260 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
<THFKA4>
those errors make working with Go really annoying :(
<THFKA4>
like if you're messing around and commenting things, now you have to remove the variable entirely before rebuilding
<THFKA4>
c..can it be an error in release build only?
<emekankurumeh[m]>
andrewrk: on windows that produces an executable with 4KB
<emekankurumeh[m]>
hello_windows produces a 2KB executable
marler8997 has quit [Remote host closed the connection]
<darithorn>
THFKA4, true, i have messed with Go and they can get a bit out of hand.
<darithorn>
but i think if they are only limited to variables that may contain errors, which i don't think is too often, then it should be okay
kristoff_it has joined #zig
<tgschultz>
I agree with THFKA4
<Tetralux>
darithorn: "I don't think is too often" - I suspect the opposite is true, but yes xD
kristoff_it has quit [Ping timeout: 258 seconds]
<darithorn>
haha maybe
halosghost has quit [Quit: WeeChat 2.5]
<darithorn>
maybe i should say those types of variables that go unused. I do think it fits well with zig's philosophy of perfect software
<darithorn>
having an error that isn't handled should be an error in itself
<darithorn>
i do agree Go takes it way too far giving an error on _any_ unused variable
<emekankurumeh[m]>
perhaps zig could have something like a "must_use" attribute
tdog has joined #zig
tdc_ has quit [Ping timeout: 245 seconds]
<Tetralux>
Jai reportedly has a #must directive you can mark a return value with that means you _must_ assign it to a variable.
<Tetralux>
(Jai has multiple return values and you can do things equivalent to `var x, _ = f()`
<Tetralux>
(..which ignores the second return value.)
<Tetralux>
(..which you then can't do if it's marked #must.)
<emekankurumeh[m]>
jai reportedly had a compiler as well /a
<emekankurumeh[m]>
*/s
<Tetralux>
hahahahahahahahahahahaha /s xD
<wrl>
there's more jai fanfiction than there is jai canon at this point
<Tetralux>
I will simply say that if Jai does get released at some point, I will be making use of that.
<Tetralux>
I do like Zig's attempt to mitigate the need to step-through debug your program though.
<Tetralux>
Although..
<Tetralux>
Haven't made a big program in Zig yet.
<emekankurumeh[m]>
me as well
<Tetralux>
It may prove to become unavoidable.
<emekankurumeh[m]>
i hope it really doesn't turn out like the release of vlang
kristoff_it has joined #zig
<Tetralux>
Did the guy who made Vlang do any streams of making it?
<Tetralux>
I don't believe so right?
<Tetralux>
That honestly increases my confidence quite a bit.
kristoff_it has quit [Ping timeout: 245 seconds]
fubd has joined #zig
<fubd>
any chance of zig ever getting a `using` statement like odin's? that's a big one I miss having experimented in both a bit now
Ichorio has quit [Ping timeout: 264 seconds]
dimenus has joined #zig
kristoff_it has joined #zig
<companion_cube>
rust has this must_use attribute, for Result
fubd has quit [Ping timeout: 260 seconds]
<companion_cube>
(or at least you get a warning if you don't use the result)
kristoff_it has quit [Ping timeout: 272 seconds]
samtebbs has quit [Quit: Lost terminal]
<donpdonp>
std.fmt.allocPrint is my new favorite function
FireFox317 has quit [Ping timeout: 260 seconds]
<andrewrk>
donpdonp, it's a good one isn't it? :)
<andrewrk>
THFKA4, I'm considering that
<THFKA4>
awesome :)
<andrewrk>
one of my goals is if you're collaborating with someone, the language will encourage them to not commit any code that is in an unfinished state
<andrewrk>
errors for unused variables are annoying but they do align with that goal
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
brakmic has quit []
cheesy has joined #zig
lunamn has quit [Ping timeout: 245 seconds]
lunamn has joined #zig
<geemili>
Compiling hello world with `-target armv7-linux-musleabi` gives a compile error with syscalls not being found; is armv7 unsupported right now?
<andrewrk>
if you're interested in contributing to the standard library, zig's lazy analysis means that you only have to fix that which your application depends on in order to get it to work
<geemili>
Ah, okay
<geemili>
So the architecture is supported, but not the stdlib?
<andrewrk>
the architecture is supported but the part of the zig std lib that interfaces with linux needs some work for this target to be better supported
ltriant has joined #zig
<geemili>
Okay
brett-soric has joined #zig
<andrewrk>
geemili, you can disable some features and get a working hello world for that target
<geemili>
Do you know if I could I build an app that uses zig for the business logic?
<geemili>
Oh
<andrewrk>
zig build-exe ../example/hello_world/hello.zig --library c -target armv7-linux-musleabi --single-threaded --strip
<andrewrk>
this successfully creates hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
<scientes>
geemili, what's your use case?
<scientes>
I did the arm64 and armhf is not that difficult, EXCEPT for the C ABI, which is quite a PITA
<scientes>
(and we don't have the C ABI for arm64 either)
marijnfs has quit [Quit: WeeChat 2.4]
<geemili>
scientes: I'm want to build an desktop program and an android app that share their "business logic"
<scientes>
why is arm64 not usable?
<scientes>
most androids are arm64 these days
<geemili>
`aarch64`?
<scientes>
even the really cheap $50 phones
<scientes>
yes aarch64
<geemili>
I did build a `aarch64` executable
<scientes>
yeah it has support because of me
<scientes>
I am just not sure if armhf is worth it, as it doesn't have much of a future
<scientes>
ARM8-M does, but that doesn't use syscalls
<scientes>
even though it is 32-bit
<geemili>
But when I tried to run it in Termux I got an `exec format error` message
<scientes>
maybe your android is ancient?
<scientes>
or maybe you are compiling against glibc
<scientes>
instead of statically against musl
<scientes>
geemili, what does file foo tell you?
<geemili>
This is the command I used to compile: `~/downloads/zig/zig-linux-x86_64-0.4.0+fcc0728a/zig build-exe hello.zig -target aarch64v8-linux-musleabi`
<scientes>
(or with a libc)
<scientes>
yeah i want the output of "file"
<scientes>
*without a libc
<scientes>
and as I was saying, you may run into problems where it refused to build against C, because the C ABI is not implemented
<andrewrk>
scientes, those errors will only occur if you have functions that would require doing the C ABI
<andrewrk>
and they would manifest as the zig compiler crashing or emitting a compile error
<scientes>
that is correct
<scientes>
I don't thing it does bad code gen
<andrewrk>
yeah I took care to avoid bad code gen
<andrewrk>
nobody wants to debug that
Flaminator has quit [Disconnected by services]
Flaminator has joined #zig
<geemili>
`file hello`: `hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, with debug_info, not stripped`
<scientes>
hmmmm, what does `uname -a` in termux give you?
<scientes>
or uname -m
hio has quit [Quit: Connection closed for inactivity]
<geemili>
`armv7l`
<geemili>
My phone is a Moto G5 Plus, I believe
<scientes>
well there is your problem
<scientes>
you need a newer phone
<andrewrk>
or you can contribute to zig std lib for that target :)
<geemili>
Yeah
<geemili>
Hmm, so theoretically, if I just implement the syscalls that zig complains, everything should work?
<geemili>
Well, maybe not "just"
<andrewrk>
yes
<scientes>
uhhhhhhhh I just got armv7l from termux on my armv8 phone
<scientes>
so I think they are shipping armv7 for some reason
<scientes>
or maybe android has a armv7 user-land and aarch64 kernel
<scientes>
to conserve memory with 32-bit pointers
<scientes>
but in that case, why would it use linux's personalities to lie to programs that it is armv7l?
<geemili>
I looked up the chip my phone has, and according to wikipedia it's Armv8
<scientes>
yeah android is a 32-bit user-space, but it would still work for static binaries except they must be using personalities (man setarch)
<scientes>
try "setarch64"
<scientes>
and then run it
<scientes>
"setarch linux64"
nifker has quit [Quit: nifker]
<scientes>
hmm if i do "setarch linux32" x86_64 binaries still work
<geemili>
Termux doesn't appear to have that command
<geemili>
I wonder if it's actually Android that's enforcing the arch
<scientes>
I'm looking at the kernel config and there is no way to turn off 64-bit syscalls (on mainline)
<scientes>
all i can think of is trying to use -fPIC
<scientes>
because android DOES require that for shared libraries
<scientes>
but i doubt it has any way to enforce it for static binaries