IRC channel logs
2024-02-09.log
back to list of logs
<oriansj>stikonas: yeah, I refuse to accept 1[a] when accessing an array. I know it violates the C spec but they can pound sand on that one. Array access and pointers should not be interchanged. Heck arrays should have proper bounds checking by default. <stikonas>yaeh, I was not aware of that 1[a] syntax until today... <oriansj>to be honest C would be better if arrays were defined as: typedef struct { TYPE _TYPE; u64 len; POINTER data; } array; <oriansj>then array foo = heap_array(uint32_t, 42); or array foo = stack_array(uint32_t, 42); foo[i] = 32; can then be checked against i prior to trying to assign to foo[i]; and thus if i >= 42; you can throw an array bounds exception and halt (or if you add exception handling logic, a way to deal with it) <fossy>yeah.. with hindsight fat pointers would have been much better <oriansj>well null terminated strings are very simple to implement (literally only 2 assembly instructions) <oriansj>but yes being able to do foo.length on strings and arrays enables certain nice efficient sanity checks. <oriansj>and it would allow heap garbage collection to be implemented independent within the language (as every object would have a known size at runtime) <stikonas>yeah, I understand why we ended up with null terminated strings. In assembly it is indeed easier to work with <stikonas>you don't need to keep track of two variables <Googulator>AFAIK even in the standard, 1[a] != a[1] unconditionally <Googulator>1+a == ((int) 1 ) + ((int) a), but a+1 = ((int) a) + (((int) 1) * sizeof(A)), where A is the type of a <sam_>or is this a parallel effort <Googulator>(early XZ support & usage, reduces bare metal image size to 210MiB) <oriansj>sam_: looks like a parallel effort; because if it was mentioned here before, I would have had a copy <oriansj>Googulator: that is about the capacity of a Mini-CD <fossy>Googulator thanks will review shortly <fossy>i cannot really understand that project <fossy>comparatively their binary seed is huge <sam_>not a fan of their huge generated build system either <sam_>the gcc 4.7 work is really orthogonal to that.. <Googulator>...I take that back, checksums aren't properly there <Googulator>updated again, this time with the correct checksums <Googulator>snuik: later tell stikonas amd64 and riscv64 checksums might need updating too <matrix_bridge><Andrius Štikonas> Yeah, those are often broken... Maybe we can update then with future mes 0.26.1 or 0.27 <oriansj>sam_: looking closer to that project, I noticed something odd: "All files are copyright Huawei Cloud Computing Technology Co., Ltd". So it isn't some individual's project. <oriansj>and if anyone is of the paranoid sort, the repo was made just 2 months after a US government report suggested bootstrappable toolchains. <Googulator>Does meslibc have an atoi / strtoul / similar function? <Googulator>I'd like to use it for killing the hardcoded INITRD_MB & KEXEC_MB values. <oriansj>Googulator: grep -iR atoi ; says yes <Googulator>also, does kaem handle quoted parameters correctly? <Googulator>i.e. can I do kexec-fiwix -c "fiwix console=/dev/tty1 root=/dev/ram0 ramdisksize=%d initrd=fiwix.ext2 kexec_proto=linux kexec_size=%d kexec_cmdline=\"init=/init consoleblank=0\"" /boot/fiwix ? <matrix_bridge><Lance R. Vick> Just noting that I too have now seen the hash mismatch error with savannah. <matrix_bridge>ERROR: failed to solve: digest mismatch sha256:d9f8d77083bb4b6367eced93e0dcaed23b759a9c3cb12c28ca75c47d8e9272e6: sha256:2d911c2f2ed97b347d6d360b742abdc98aa626d4f8f847ee682c7cde12e90871 <matrix_bridge>Got the same bad hash 3 times in a row then fetched correctly on the third time. Sadly I don't have a copy of the bad file, but just flagging it. <civodul>those auto-generated tarballs tend to change over time