00:00:13 -!- somefan has quit (Remote host closed the connection).
00:00:21 -!- somefan has joined.
00:02:52 <ais523> I just came to a sudden realisation about Rust, and wanted to write it down somewhere before I forgot it, and I guess #esoteric will do: an aligned/nonnull raw pointer to T is basically just an &UnsafeCell<T> whose lifetime isn't tracked
00:03:39 <ais523> there's already a special-case rule that says an &UnsafeCell can exist even if the inside of the cell doesn't contain valid data, and I think this is where it comes from
00:06:17 <ais523> this fits in with an observation I had a while ago (but didn't post), that when working with raw pointers in Rust they seem to want to be created by doing something to a mutable reference – &mut T and &mut UnsafeCell<T> are equivalent (safely interconvertable either way using UnsafeCell::from_mut and UnsafeCell::get_mut), then you pirate the &mut UnsafeCell<T> to get an &UnsafeCell<T>
00:07:46 <ais523> actually, you can create raw pointers to uninitalized memory too, so maybe an aligned/nonnull raw pointer is &'unsafe UnsafeCell<MaybeUninit<T>>
00:08:29 <ais523> ('unsafe isn't actual Rust syntax but it's a fairly well-known proposal at this point)
00:08:59 <ais523> hmm, I guess this is the exact opposite of rubber-ducking, instead of asking questions into the void to help me understand something, I'm making statements into the void to help me express something
00:12:54 <b_jonas> ais523: you aren't allowed to have an &UnsafeCell<T> point to the same address as an &mut UnsafeCell<T> unless you reborrowed from the latter, but you can have a raw pointer point to the same address as the &mut UnsafeCell<T>, so I don't think they're the same
00:13:54 <ais523> b_jonas: so the trick here is: if your raw pointers can only be created by pirating the &mut UnsafeCell<T>, they're all derived from a share of that mutable borrow and so they're allowed
00:14:19 <ais523> in fact, I think the original &mut UnsafeCell<T> is what a provenance is
00:15:16 <ais523> if you offset them out of bounds you can't read or write through them until they're back in bounds
00:15:38 <b_jonas> this seems to me kind of a narrow view of raw pointers
00:15:50 <ais523> so even if they're matching the address of some other &mut it's OK, as you need the read or write to break the rules
00:15:53 <b_jonas> it's certainly one thing you can use raw pointers too, but surely there are others
00:17:05 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172493&oldid=172489 * A() * (-32)
00:17:08 <ais523> under the current rules there are "raw pointers to memory outside the Rust virtual machine", but that's one of the special cases I've been actively working on trying to combine into the general case
00:17:49 <ais523> and there are raw pointers without provenance, too, but you can't actually read or write through them so they don't cause any aliasing conflicts
00:19:54 <ais523> the situation with aliasing is a little complicated because the rules that safe Rust implies (that an &mut T is never allowed to alias an &T not derived from it) is different from the rules that unsafe Rust is allowed to use (unsafe Rust currently allows them to alias unless both of them are accessed through – if one of them is unused it's OK – but it's unsafe because using a reference is a safe operation)
00:20:37 <b_jonas> I thought that's still forbidden in unsafe rust in general.
00:21:47 <ais523> so there is a model of unsafe Rust called Stacked Borrows, which is the de-facto standard at the moment – most unsafe Rust programmers are willing to do anything that's legal in Stacked Borrows and the compiler avoids doing optimisations that conflict with it
00:22:15 <ais523> but, it is not necessarily the final model – but it's considered much more likely for parts of it to be relaxed than parts of it to be made stricter
00:22:42 <b_jonas> that's why rust added the &raw syntax recently, because you're only allowed to have a reference if it always points to a readable object with a valid representation. I know you work that around above with MaybeUninit, but still.
00:23:08 <ais523> Stacked Borrows doesn't look at lifetimes at all when considering whether code is valid or not, just for the first/last use of each given reference (although there is a somewhat confusing "protectors" rule which means that some rules apply for the rest of a function body, even past the last use)
00:23:47 <ais523> the reason &raw exists is partly because of that, and partly because if you go via a reference you narrow the provenance
00:24:15 <b_jonas> sure, lifetimes belong to safe rust, that's how safe rust proves at compile time that it doesn't do anything that would be forbidden in unsafe rust, and unsafe rust is allowed to ignore lifetimes using an unsafe cast of pointer to reference
00:24:35 <ais523> ah right, so the problem isn't "I convert this to a reference and then to a pointer, and the reference aliases something so it's UB"
00:24:50 <b_jonas> but typed references and typed mut references still have strict rules in unsafe rust
00:25:16 <ais523> the problem is "I convert this to a reference and then to a pointer, and the reference aliased something, so *when I use the pointer* it is trying to use the reference's provenance and so the fact that the reference aliased something then causes UB now"
00:26:15 <esolangs> [[User talk:FluixMakesEsolangs]] https://esolangs.org/w/index.php?diff=172494&oldid=172471 * * (+35)
00:26:32 <ais523> I guess the way to look at it is that a reference that illegally aliases something isn't insta-UB, but it screws up the reference's provenance, so anything that you subsequently try to do with pointers derived from it is UB
00:27:29 <ais523> and you might as well express this rule as "references aren't allowed to illegally alias things"
00:29:38 <esolangs> [[Esolang talk:Categorization]] https://esolangs.org/w/index.php?diff=172495&oldid=172491 * A() * (+206) /* Groups */
00:30:51 <b_jonas> I guess you are allowed to point an UnsafeCell anywhere, but I don't think that's an informative way to think of all raw pointers, simply because you aren't guaranteed to be able to do anything with an UnsafeCell
00:33:51 <esolangs> [[User:A()]] https://esolangs.org/w/index.php?diff=172496&oldid=172252 * A() * (+10)
00:34:56 <esolangs> [[ASTLang (Fast Lookup)]] https://esolangs.org/w/index.php?diff=172497&oldid=172315 * NTMDev * (-169) Blanked the page
00:35:22 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=172498&oldid=172317 * NTMDev * (-281)
00:38:18 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=172499&oldid=172498 * NTMDev * (+307) /* PrimitiveWrapper (DEPRECATED) */
00:38:37 <esolangs> [[ASTLang]] https://esolangs.org/w/index.php?diff=172500&oldid=172499 * NTMDev * (-133) /* Types */
00:42:31 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172501&oldid=172493 * A() * (+30)
00:43:07 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172502&oldid=172501 * A() * (+0)
00:43:24 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172503&oldid=172502 * A() * (+0)
00:43:53 <b_jonas> a raw pointer could have arithmetic done on it to store extra info, or it could point to a function or to an atomic. I think you're still allowed to make an &UnsafeCell from it in those cases, but you can't use that &UnsafeCell for anything, so I don't think UnsafeCell helps imagine what raw pointers can do.
00:43:55 <esolangs> [[GTPS]] https://esolangs.org/w/index.php?diff=172504&oldid=172503 * A() * (+0)
00:44:14 <b_jonas> (other than casting that &UnsafeCell back into a raw pointer)
00:46:16 <b_jonas> (well no, technically you can also pass it as an &UnsafeCell to a foreign function, but it would be strange to declare the function that way rather than with a raw pointer)
00:46:46 <b_jonas> (or you can reinterpret the bits of the reference as a pointer, they're represented the same)
00:47:49 -!- somefan has quit (Remote host closed the connection).
00:47:57 -!- somefan has joined.
00:49:12 <sorear> are atomics something different from non-atomics? i thought that was a property of the access, not the object
00:49:50 <sorear> is "raw pointer pointing to a function" something different from the general case of "raw pointer to the wrong type"?
00:50:31 <b_jonas> sorear: it's technically a property of the access, but you can cast a raw pointer to a raw pointer of any other type so *anything* is a property of the access at that point.
00:51:41 <b_jonas> as for raw pointer pointing to a function, only in as much that I think some C APIs use a C pointer to void instead of a pointer to a function whose type isn't known until runtime, which is odd but not really wrong
00:52:46 <sorear> that's allowed by POSIX as an extension but not in general legal C, e.g. x86-16 MEDIUM model
00:53:43 <b_jonas> no, C specifically allows that for void pointers
00:54:30 <b_jonas> C says that void pointers can represent pointers to functions or pointers to any type of object, it's safe to cast any of those to void pointer as long as you cast back before use
00:55:46 <b_jonas> (also any pointer to a struct/union can represent a pointer to any other struct/union, but that's mostly so that pointers to not incomplete structs can work sanely with a specific representation, which you use if the struct will either be delcared later or only in other compilation units)
00:56:19 <b_jonas> other pointer types can be more restricted, but void pointers are magic in C
00:56:42 <b_jonas> ok, not really magic, just have strong guarantees
00:58:21 <int-e> AFAICS &UnsafeCell<T> must be properly aligned because it had to point to valid memory when it was constructed: "whenever a &UnsafeCell<T> is constructed or dereferenced, it must still point to live memory"
01:00:12 <b_jonas> if you want something that needn't be able to point to a function the you can use a pointer to struct, kind of. I think the C standard allows that all structs are 4-byte aligned even when you have 1-byte and 2-byte integer types, and pointers to struct could be such that they can only represent 4-aligned addresses, so if you want to do this you'll have to wrap anything you want to point to into a
01:00:18 <b_jonas> struct. But I don't think C behaves like that on any real architecture.
01:00:26 <b_jonas> int-e: yes, but ais523 did say aligned and non-null
01:01:52 <ais523> <sorear> are atomics something different from non-atomics? i thought that was a property of the access, not the object ← it's a property of the access *but* there's no useful way to correctly mix atomic and non-atomic accesses, so it makes sense for the type system to dictate what sort of access you're using
01:02:25 <int-e> b_jonas: Maybe I read something into https://logs.esolangs.org/libera-esolangs/2026-01-08.html#lR that you didn't intend to say, but to me it sounded like you were suggesting that you could, say, put a tagged pointer into a &UnsafeCell<T>
01:02:37 <ais523> <b_jonas> no, C specifically allows that for void pointers ← I also thought function pointers were an exception to this, ahs something changed?
01:03:32 <ais523> int-e: you can't do that specifically due to representation validity reasons (the compiler is allowed to assume that references haven't been tagged, even if you don't read through them, and uses this allowance to collapse enum size) – I don't think there are any provenance reasons why you couldn't do it though
01:03:52 <int-e> ais523: that's what I said just before?
01:04:05 <ais523> int-e: sorry, pings are confusing
01:04:17 <ais523> I was mostly replying to b_jonas but trying to quote your comment by reference
01:04:36 <ais523> I have realised recently that my use of pings on IRC is more to do with whether I am replying to a previous comment specifically than with who I am replying to
01:05:52 <ais523> recently someone posted two comments, I replied to the second one with no ping, then replied to the first one with a ping, I think that's another example of the same sort of phenomenon (I think I subconsciously decided to gave the ping because the referent wouldn't be obvious otherwise)
01:06:32 <ais523> …and now I'm realising that I have somehow managed to subconsciously create a new language convention that uses existing communication mechanisms for a purpose entirely different from the recommended or generally understood one
01:07:00 <sorear> languages aren't real, it's idiolects all the way down
01:07:28 <korvo> ais523: I think of it as like when I'm doing dishes and talking to somebody. Pinging is like looking up, making eye contact, and ensuring that I've gotten a point across. More practically, I use pings to indicate that I think that the recipient might want to read what I'm saying.
01:08:56 <b_jonas> int-e: I can understand if you read it that way, but yes, you may still need the pointer to be aligned and it definitely needs to be non-null if you want to make an UnsafeCell there, and since ais523 mentioned that I didn't repeat.
01:09:54 <ais523> references being aligned and non-null is a validity thing, otherwise type like Option<&T> wouldn't work properly (it relies on references always being non-null, even if they're never used, to be able to distinguish Some(null) from None)
01:10:42 <ais523> if not for that rule an &UnsafeCell<T> to null would actually work, as long as you never read or wrote it (there's a specific rule saying that you can free/unmap the memory behind an &UnsafeCell)
01:11:17 <ais523> and because the compiler has to allow for the possibility that the memory is unmapped, it won't do anything that wouldn't work with null, because null is also just unmapped memory from the processor's point of view
01:15:21 <b_jonas> you're right. sorear: sorry, I was wrong about function pointers, C doesn't claim that you can convert them to void * and back. I don't know why I thought it did.
01:21:20 <b_jonas> Rust rules have been relaxed to allow some limited mixing of atomic with non-atomic, though I hvaen't processed the details of whether this is useful. In particular, I don't understand if you can just zero memory and transmute it instead of initializing a rust atomic.
01:22:27 <ais523> b_jonas: an &mut can be reborrowed as an &Atomic
01:22:55 <ais523> the basic way to think about it is that all the cell-like types can be switched between if you have a mutable reference, but not if you don't have a mutable reference
01:24:05 <b_jonas> ais523: ok, but if you reborrow that way, will it give a definite value if you atomic read it, and the same as if you had read it as an integer instead before reborrowing as an atomic?
01:24:45 <ais523> you can think of the Atomic types as basically being thread-safe versions of Cell
01:24:50 <ais523> that are limited to primitive types
01:27:36 <b_jonas> sure, that's how they're implemented, but I want to know what's actually guaranteed about them in a future-proof way. this is relevant eg. if you want to atomic access the same atomic objects from rust and some other language concurrently
01:28:21 <ais523> memory in Rust is not typed – the only type-like thing about it is whether it carries provenance
01:28:53 <ais523> the rules about atomics are basically that accesses that *aren't* atomic can't race with each other, but accesses that are atomic can
01:29:07 <ais523> (if there is a race, both accesses need to be atomic)
01:29:48 <ais523> so if you have any reason to use atomics in the first place (i.e. races exist), you then have to somehow prove that the races have stopped existing before you can do non-atomic accesses on the same memory
01:30:13 <ais523> (prove to the compiler in safe Rust, or prove to yourself in unsafe Rust)
01:34:42 <b_jonas> ais523: so one weird thing that I could imagine is this. Say you have an ARM-like CPU that has arithmetic only between registers, but has both little-endian and big-endian 16-bit and 32-bit integer load and store instructions. So the C ABI has to pick one of big-endian or little-endian, it picked one of them and that spread. Then a later extension of the CPU adds an atomic compare and exchange
01:34:48 <b_jonas> instruction, but only one endianness. Then you could end up with a C ABI where integers have the opposite endianness from atomic integers, and then the Rust ABI will match that too.
01:35:08 <b_jonas> Or the same but it's only 128 byte sized atomic compare an exchange instructions that are in one endianness only.
01:35:36 <b_jonas> You could still manipulate atomics of any endianness, the other endianness just takes an extra instruction or two to byteswap your registers.
01:36:15 <ais523> b_jonas: AtomicUsize::from_mut / AtomicUsize::get_mut (unstable) would probably deal with the conversion, although it seems unlikely that such a situation would end up happening
01:37:01 <ais523> in practice I would expect all modern processors to use the same endianness for integers as they do for pointers, and normally pointers have to be pushed to the stack automatically by the hardware sometimes
01:37:15 <ais523> but I can just about imagine having a link register and an interrupt link register to avoid that
01:37:58 <sorear> that's how pretty much all of the RISCs work except SuperH
01:38:41 <sorear> arm1 exceptions store the PC into a general register, but R14/R15 are banked in all modes so it works out the same
01:39:25 <ais523> in any case, most processors that can't do arithmetic on memory use LL/SC as their atomic primitive rather than CAS
01:39:43 <ais523> although I guess it's possible that LL/SC would only work on one endianness but MOV would work on both
01:40:02 <ais523> load-linked/store-conditional
01:40:15 <sorear> if you think of registers as being a sequence of bytes LL/SC and CAS are both endian agnostic
01:40:40 <ais523> the way it works on most processors is that LL loads a value from memory and also marks some amount of surrounding memory as busy
01:40:55 <ais523> and SC stores to memory, but only if none of the memory busied by the most recent LL instruction has been touched since
01:41:33 <ais523> otherwise it does some sort of error return instead
01:42:10 <b_jonas> ais523: so that's like compare and swap but it's allowed to spuriously fail?
01:42:31 <ais523> (ideally LL would busy only the specific value you loaded, but normally it has to busy at least a cache line)
01:42:43 <ais523> b_jonas: can indeed spuriously fail, but also it doesn't have the ABA problem
01:42:45 <b_jonas> I think that's https://doc.rust-lang.org/nightly/std/sync/atomic/struct.AtomicI32.html#method.compare_exchange_weak
01:43:05 <sorear> you can emulate "wrong endian" xadd/amoadd/ldadd using a LL/SC or CAS loop but the emulation has different lock-free/wait-free properties than native xadd/amoadd/ldadd
01:43:14 <b_jonas> I mean at the CPU level it would have somehwat stronger guarantees on when exactly it can spuriously fail
01:43:28 <ais523> b_jonas: memory gets written to twice during an atomic sequence and ends up with its old value, so when you do the compare-and-swap at the end you think it hasn't chagned
01:43:49 <sorear> the ABA thing is an urban legend, LL/SC is stronger than CAS if you can do unrelated memory operations in the middle but this is not actually allowed by any ISA specification
01:44:09 <ais523> this can be problematic if, e.g., the atomic value is a pointer and you are relying on the pointer not having changed to indicate that the value it points to hasn't changed (e.g. because it doesn't change for as long as it's in the variable)
01:44:45 <ais523> because if in the middle of your compare-exchange loop, someone took out the pointer, changed the memory it points to, and put it back again, it'll look like nothing happened but now your information is stale
01:44:50 <sorear> LL immediately followed by SC is observably equivalent to CAS because you can postdate the successful LL and pretend it happened at the same time as the SC
01:45:08 <b_jonas> ok, I think this doesn't change much in how I imagine atomics could represent numbers differently than integers
01:45:29 <b_jonas> but it's still interesting
01:45:32 <ais523> sorear: LL immediately followed by SC is a swap, isn't it? (rather than a compare-and-swap)
01:45:44 <ais523> if you want a compare-and-swap you need to actually do the compare in between
01:46:03 <sorear> "immediately" in the sense of the local memory order
01:46:11 <b_jonas> it explains why so many functions that are generic between CPUs are defined to allow spurious fails where you have to retry
01:46:15 <ais523> yes, in that case it doesn't give you any extra power I think
01:46:26 <b_jonas> some of the spurious failures may be introduced at a higher levle
01:46:38 <ais523> one thing that surprised me about this is just how much memory typically gets busied by the LL in practice
01:46:56 <ais523> realistically it has to be at least a cache line, but often it's somewhere around a kilobyte, which is surprisingly large to me
01:47:10 <ais523> of course, usually you get away with it because the LL and SC are so close together
01:48:43 <sorear> it's mostly unobservable outside performance because the SC is allowed to fail spuriously
01:49:13 <ais523> b_jonas: oh! there's a subtlety I forgot about converting between atomics and nonatomics – atomics have bigger alignment on some platforms
01:49:47 <ais523> e.g. u64 sometimes has 4-byte alignment on 32-bit platforms, but AtomicU64 has 8-byte alignment basically everywhere because it's hard to stop it straddling a cache line otherwise
01:50:14 <sorear> the Rocket implementation starts a ~16 cycle timer when it sees a LL, refuses remote invalidations while the timer is active, and succeeds SC if the timer is active and the address matches
01:50:20 <ais523> that said, IIRC misaligned atomics actually work on x86(-64) except for the double-register ones
01:50:31 <b_jonas> that's reasonable. cache lines are small because the data actually has to be moved, and there are physical limits to how many bits fit through the wires quickly, but synchronization between CPU threads could be less fine-grained.
01:50:36 <ais523> and the processor has to be able to lock two cache lines because of that
01:51:23 <ais523> (this still doesn't mean that any sensible compiler/language will let you define misaligned atomics, though)
01:53:05 <b_jonas> ais523: yeah, x86_64 mostly tolerates unaligned accesses surprisingly well. there are some cases when they don't work, but it's mostly (1) the MOVDQA instruction that exists for historical reasons because it used to be faster in old CPUs but these days has no advantage over MOVDQU, (2) one flag that you can specifically set to disallow certain unaligned vector accesses, probably to catch code that
01:53:11 <b_jonas> mistakenly does unaligned access, and (3) system-related stuff like page tables.
01:53:26 <ais523> b_jonas: and the alignment check flag!
01:53:49 <ais523> no, it controls non-vector accesses specifically
01:53:56 <sorear> riscv has misaligned atomics within an aligned 16byte region as a feature "intended to be mandatory in a future profile", nobody will say what the actual use case for this is
01:54:12 <ais523> only 16-, 32- and 64-bit accesses cause alignment traps, anything larger (or smaller) can't
01:55:14 <ais523> AVX and later allow misaligned vectors unless you are using a specifically aligned instruction like MOVDQA, but SSE instructions fault on misaligned vectors, so that's one way to custom alignment behaviour on vector instructions (as long as they're old enough)
01:55:28 <sorear> I think AC mostly exists as a migration aid from when they weren't quite sure what the IA-32 successor was and whether it would support misalignment
01:55:29 <b_jonas> I think originally the unaligned was because the 8088 got popular and people wrote code for it that did unaligned access, and some of the supposedly undocumented IBM PC BIOS variables at unaligned addresses ascended to de facto public API that every clone had to support. But I don't know why it got continued so far.
01:56:12 <ais523> AVX encodings should in theory be faster due to zeroing the top of the register rather than leaving it alone (and causing a false dependency)
01:56:13 <sorear> debian's current m68k ABI has sizeof int = 4, _Alignof int = 2
01:56:54 <int-e> b_jonas: disassembling network packets and concatenated files and the like may just be useful enough
01:56:59 <ais523> but it turns out that recent Intel has a sticky "some of the vector registers have data beyond the bottom 16 bytes" flag that isn't vector-specific, meaning that you get the false dependency even with AVX instructions
01:57:08 <ais523> (the only ways to clear it are VZEROUPPER/VZEROALL)
01:57:17 <ais523> * that isn't specific to a particular vector register
01:57:47 <int-e> b_jonas: plus the fact that within the same cache line you can do this "for free"
01:57:58 <ais523> this strikes me as a terrible idea, but Intel probably think they can get away with it because compilers do VZEROUPPER anyway to support linking against SSE libraries (and depressingly, they may be right)
01:58:40 <ais523> in any case this means that on recent Intel, SSE encodings have no actual downside over the AVX equivalent
01:58:45 <b_jonas> int-e: yes, that can be a good reason
01:59:11 <sorear> useful in string functions too
01:59:13 <ais523> because both of them have to write both halves of the register if the second-16-dirty flag is set, and neither of them do if it's clear
01:59:49 <ais523> but it also means you can't use different widths of vector at the same time
01:59:50 <sorear> or say you have a struct (necessarily with several fields) with size 8, align <8. wouldn't it be nice to copy it with one instruction?
02:00:05 <ais523> (you *can* but you will get all operations acting at the speed of the largest vector you're using)
02:00:29 <ais523> sorear: why does that need to be atomic, though?
02:00:31 <sorear> do they still have the scratchpad?
02:00:35 <b_jonas> I kind of wish compilers just had four first-class variants for their integer types according to whether they are aligned and their endianness. You can implement this as just library types, and it has been implemented in C++ a few times, but I feel like compilers could implement it easier.
02:00:46 <sorear> ais523: it needs to not fault
02:00:47 -!- scoofy_ has joined.
02:01:37 <b_jonas> (Possibly six types if native endianness is considered different from both big and little endianness in the same way as C int and long and long long are three different types even if they're just two different representations.)
02:01:47 <ais523> sorear: right, but couldn't the feature just say "you need to be able to read/write misaligned data nonatomically within a cache line", rather than supporting atomics too?
02:02:38 <ais523> b_jonas: this goes back to the whole distinction between storage representations and register representations
02:02:47 <sorear> those weren't connected, I thought the conversation had moved to "why is unaligned access allowed at all"
02:03:12 <ais523> <sorear> riscv has misaligned atomics within an aligned 16byte region as a feature "intended to be mandatory in a future profile", nobody will say what the actual use case for this is
02:03:22 <ais523> and then you started justifying it in the non-atomic case, which I agree iwth
02:03:33 <b_jonas> I guess a hypothetical new CPU architecture could even have unaligned reads just work like x86, but unaligned writes raise a fault.
02:03:55 <ais523> the best use I can think of in the atomic case is to somehow store more data in an atomic-safe way by using overlapping atomics
02:04:13 -!- scoofy has quit (Ping timeout: 264 seconds).
02:04:42 <ais523> b_jonas: if it's doing that, it would be great if it faulted only on entirely unmapped memory and just returned zeroes for partially unmapped memory
02:04:56 <sorear> misaligned load/store *without* atomicity guarantees is already required in all application profiles
02:04:59 <ais523> although the problem there is that hardware normally can't distinguish between memory being unmapped and paged out
02:05:55 <b_jonas> ais523: like for strlen? I dunno, it could make sense
02:06:34 <sorear> troll option: byte level NaT
02:06:54 <b_jonas> I have considered a mode in my C interpreter where any read from invalid memory silently reads 0, while writes fail, but you're right that at a hardware level this would be much harder
02:07:08 <ais523> sorear: that's not quite a troll option if it applies at the byte level in registers but the page level in memory
02:07:43 <ais523> also it's basically how LLVM's virtual machine works
02:24:58 <esolangs> [[Special:Log/newusers]] create * MtPenguinMonster * New user account
02:26:37 <esolangs> [[Esolang:Introduce yourself]] https://esolangs.org/w/index.php?diff=172505&oldid=172451 * MtPenguinMonster * (+202) /* Introductions */
02:28:20 -!- amby has quit (Quit: so long suckers! i rev up my motorcylce and create a huge cloud of smoke. when the cloud dissipates im lying completely dead on the pavement).
03:14:38 -!- impomatic has joined.
03:31:52 -!- impomatic has quit (Quit: Client closed).
05:27:22 -!- ais523 has quit (Quit: quit).
06:37:45 -!- molson__ has quit (Remote host closed the connection).
07:12:03 <esolangs> [[Gur yvsr]] https://esolangs.org/w/index.php?diff=172506&oldid=172492 * Placeholding * (+93) clarified how a conditional and a conditional destination correspond
07:17:27 -!- somefan has quit (Remote host closed the connection).
07:25:42 -!- tromp has joined.
08:07:04 <esolangs> [[Brainpocalypse II]] https://esolangs.org/w/index.php?diff=172507&oldid=164875 * Yayimhere2(school) * (+17) /* See also */ add goto start, very similair languages!
08:10:05 -!- Sgeo has quit (Read error: Connection reset by peer).
08:49:49 -!- b_jonas has quit (Quit: leaving).
09:03:32 <esolangs> [[USI]] N https://esolangs.org/w/index.php?oldid=172508 * Yayimhere2(school) * (+2643) Created page with "'''USI''', short for Unknown Source of Intervention, is a language based on the method of implementing of compiling one language to another, in which a counter is used as the program counter, and then when it has a certain value, a certain effect takes place. It
09:06:19 -!- Yayimhere has joined.
09:11:50 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
09:36:35 -!- Yayimhere has quit (Ping timeout: 272 seconds).
10:05:47 <esolangs> [[User:Yayimhere]] https://esolangs.org/w/index.php?diff=172509&oldid=172452 * Yayimhere2(school) * (+64) /* esolangs */
10:27:02 -!- scoofy_ has changed nick to scoofy.
10:27:13 -!- scoofy has changed hostmask to ~scoofy@user/scoofy.
10:36:34 -!- tromp has joined.
12:05:51 -!- b_jonas has joined.
12:07:23 -!- somefan has joined.
12:15:34 <esolangs> [[DeltaLang]] N https://esolangs.org/w/index.php?oldid=172510 * PrySigneToFry * (+5909) Created page with "DeltaLang is designed by PSTF. It is a formal programming language, roughly designed in [https://funcode.miraheze.org/wiki/Gdel's_Incompleteness_Theorems_vs_Programming_Languages Gdel's Incompleteness Theorems vs Programming Languages]. Note, the DeltaLang reco
12:27:35 <esolangs> [[User:Hotcrystal0/Sandbox]] https://esolangs.org/w/index.php?diff=172511&oldid=172480 * Hotcrystal0 * (-2)
13:16:40 <esolangs> [[User:Blashyrkh/Crazy J]] https://esolangs.org/w/index.php?diff=172512&oldid=172199 * Blashyrkh * (+17476) Sequential tag system implementation
13:42:43 -!- pool has quit (Read error: Connection reset by peer).
13:43:10 -!- pool has joined.
14:46:46 -!- impomatic has joined.
14:47:43 <esolangs> [[BrainTrix]] https://esolangs.org/w/index.php?diff=172513&oldid=170948 * JIT * (+10)
14:48:13 <esolangs> [[Hata hata hata ton]] https://esolangs.org/w/index.php?diff=172514&oldid=171054 * JIT * (+24)
14:49:14 <esolangs> [[AddByteNegJump]] https://esolangs.org/w/index.php?diff=172515&oldid=171056 * JIT * (+42)
14:49:32 <esolangs> [[AddSys]] https://esolangs.org/w/index.php?diff=172516&oldid=171083 * JIT * (+23)
14:49:47 <esolangs> [[AddByte]] https://esolangs.org/w/index.php?diff=172517&oldid=171194 * JIT * (+23)
14:50:10 <esolangs> [[Memory]] https://esolangs.org/w/index.php?diff=172518&oldid=171288 * JIT * (+23) TIM
14:51:04 <esolangs> [[AddByteJump]] https://esolangs.org/w/index.php?diff=172519&oldid=172462 * JIT * (+23) its not THAT hard, TIM! just add a category:languages and tHATS it
14:55:07 <esolangs> [[Talk:USI]] N https://esolangs.org/w/index.php?oldid=172520 * Aadenboy * (+349) noticed
14:56:49 <esolangs> [[Talk:USI]] https://esolangs.org/w/index.php?diff=172521&oldid=172520 * Yayimhere2(school) * (+237)
15:00:41 -!- DOS_User_webchat has joined.
15:02:33 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172522&oldid=172508 * Yayimhere2(school) * (+17)
15:08:21 -!- Sgeo has joined.
15:10:20 -!- DOS_User_webchat has quit (Quit: Client closed).
15:16:54 -!- ais523 has joined.
15:17:06 <HackEso> olist <https://www.giantitp.com/comics/oots1338.html>: shachaf oerjan Sgeo boily nortti b_jonas Noisytoot
15:18:20 <int-e> . o O ( the wall of text comic is still going I see )
15:23:33 <esolangs> [[User talk:Blashyrkh]] N https://esolangs.org/w/index.php?oldid=172523 * Yayimhere2(school) * (+202) Created page with "Hey, you make some cool stuff!!! Would you perhaps collaborate with me on an esolang? --~~~~"
15:27:47 <esolangs> [[User:Blashyrkh/Crazy J]] https://esolangs.org/w/index.php?diff=172524&oldid=172512 * Blashyrkh * (+1209) Cyclic tag system implementation
15:36:32 <esolangs> [[User talk:Blashyrkh]] M https://esolangs.org/w/index.php?diff=172525&oldid=172523 * Blashyrkh * (+134)
15:38:08 <esolangs> [[User talk:Blashyrkh]] https://esolangs.org/w/index.php?diff=172526&oldid=172525 * Yayimhere2(school) * (+165)
15:38:30 -!- amby has joined.
15:45:16 -!- ehmry has quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.).
15:45:23 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
15:53:36 <esolangs> [[User talk:Blashyrkh]] M https://esolangs.org/w/index.php?diff=172527&oldid=172526 * Blashyrkh * (+372)
15:54:41 <esolangs> [[User talk:Blashyrkh]] https://esolangs.org/w/index.php?diff=172528&oldid=172527 * Yayimhere2(school) * (+189)
16:01:41 <esolangs> [[User talk:Blashyrkh]] M https://esolangs.org/w/index.php?diff=172529&oldid=172528 * Blashyrkh * (+402)
16:04:27 <esolangs> [[User talk:Blashyrkh]] https://esolangs.org/w/index.php?diff=172530&oldid=172529 * Yayimhere2(school) * (+136)
16:04:35 -!- tromp has joined.
16:07:01 <esolangs> [[User:Blashyrkh]] M https://esolangs.org/w/index.php?diff=172531&oldid=171679 * Blashyrkh * (+145) Link to UnnamedEsolang draft page
16:23:48 -!- ehmry has joined.
16:23:59 -!- somefan has quit (Remote host closed the connection).
16:24:09 -!- somefan has joined.
16:32:32 -!- somefan has quit (Remote host closed the connection).
16:32:43 -!- somefan has joined.
16:39:39 <esolangs> [[User:Blashyrkh/UnnamedEsolang]] N https://esolangs.org/w/index.php?oldid=172532 * Blashyrkh * (+1544) Just an idea of a language
16:39:51 -!- impomatic has quit (Quit: Client closed).
16:40:19 <esolangs> [[User talk:Blashyrkh]] M https://esolangs.org/w/index.php?diff=172533&oldid=172530 * Blashyrkh * (+131)
16:43:03 <esolangs> [[User:Blashyrkh/UnnamedEsolang]] M https://esolangs.org/w/index.php?diff=172534&oldid=172532 * Blashyrkh * (-1) typo
16:46:18 <esolangs> [[User talk:Blashyrkh]] https://esolangs.org/w/index.php?diff=172535&oldid=172533 * Yayimhere2(school) * (+321)
16:48:36 <esolangs> [[User talk:Blashyrkh]] https://esolangs.org/w/index.php?diff=172536&oldid=172535 * Yayimhere2(school) * (+31)
16:55:17 <esolangs> [[User talk:Blashyrkh]] M https://esolangs.org/w/index.php?diff=172537&oldid=172536 * Blashyrkh * (+431)
16:58:44 <esolangs> [[User talk:Blashyrkh]] https://esolangs.org/w/index.php?diff=172538&oldid=172537 * Yayimhere2(school) * (+213)
17:02:01 <esolangs> [[User talk:Blashyrkh]] M https://esolangs.org/w/index.php?diff=172539&oldid=172538 * Blashyrkh * (+168)
17:02:35 <esolangs> [[User talk:Blashyrkh]] https://esolangs.org/w/index.php?diff=172540&oldid=172539 * Yayimhere2(school) * (+182)
17:04:58 -!- somefan has quit (Remote host closed the connection).
17:05:14 -!- somefan has joined.
17:05:19 <esolangs> [[User:Blashyrkh/UnnamedEsolang]] M https://esolangs.org/w/index.php?diff=172541&oldid=172534 * Blashyrkh * (+41) some clarification
17:05:59 <esolangs> [[User:Blashyrkh/UnnamedEsolang]] https://esolangs.org/w/index.php?diff=172542&oldid=172541 * Yayimhere2(school) * (+12)
17:14:12 -!- impomatic has joined.
17:19:13 -!- ais523 has quit (Quit: quit).
17:23:09 -!- ais523 has joined.
18:05:17 -!- svm has joined.
18:07:35 -!- msv has quit (Ping timeout: 240 seconds).
18:17:45 <esolangs> [[Countable]] https://esolangs.org/w/index.php?diff=172543&oldid=172436 * Aadenboy * (+843) implement the [[Kolakoski sequence]]
18:18:01 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
18:18:44 <esolangs> [[Kolakoski sequence]] https://esolangs.org/w/index.php?diff=172544&oldid=168755 * Aadenboy * (+834) add [[Countable]]
18:18:46 <esolangs> [[User:Blashyrkh/Crazy J]] https://esolangs.org/w/index.php?diff=172545&oldid=172524 * Blashyrkh * (+4765) /* Cyclic tag system */ Compiled form of cts-sts adapter
18:20:02 -!- svm has changed nick to msv.
18:28:46 -!- tromp has joined.
18:41:17 <esolangs> [[Kolakoski sequence]] https://esolangs.org/w/index.php?diff=172546&oldid=172544 * Yayimhere2(school) * (+2) /* Countable */ == -> ===
18:45:10 -!- Everything has quit (Quit: leaving).
18:45:51 <esolangs> [[User:Blashyrkh/Crazy J]] https://esolangs.org/w/index.php?diff=172547&oldid=172545 * Blashyrkh * (+289) New rule with S combinator, update table, remove some todos
18:51:19 -!- impomatic has quit (Quit: Client closed).
18:56:14 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
19:02:20 -!- tromp has joined.
19:02:51 <esolangs> [[Countable]] https://esolangs.org/w/index.php?diff=172548&oldid=172543 * Yayimhere2(school) * (+8) make example programs have === === titles
19:06:49 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172549&oldid=172522 * Yayimhere2(school) * (+208) /* Syntax */
19:08:57 <esolangs> [[Pythong]] N https://esolangs.org/w/index.php?oldid=172550 * FluixMakesEsolangs * (+1827) Initial Creation of Page
19:08:59 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172551&oldid=172549 * Yayimhere2(school) * (+2) /* Constructs */
19:10:22 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172552&oldid=172551 * Yayimhere2(school) * (+23) /* Semantics */
19:14:30 <lambdabot> METAR EGBB 081850Z 08010KT 1500 SN OVC004 01/00 Q0986 RESN RERA
19:19:13 <esolangs> [[Apraxia]] https://esolangs.org/w/index.php?diff=172553&oldid=172381 * Yayimhere2(school) * (+8) /* Combinators */
19:23:20 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172554&oldid=172552 * Yayimhere2(school) * (+34) /* Semantics */
19:23:36 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172555&oldid=172554 * Yayimhere2(school) * (+47) /* Memory */
19:24:04 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172556&oldid=172555 * Yayimhere2(school) * (+24) /* Semantics */
19:24:53 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172557&oldid=172556 * Yayimhere2(school) * (+18) /* Semantics */
19:27:47 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172558&oldid=172557 * Yayimhere2(school) * (+0)
19:28:53 <esolangs> [[User talk:FluixMakesEsolangs]] https://esolangs.org/w/index.php?diff=172559&oldid=172494 * FluixMakesEsolangs * (+240) I eat dirt
19:29:41 <esolangs> [[User talk:FluixMakesEsolangs/Secret]] https://esolangs.org/w/index.php?diff=172560&oldid=172469 * FluixMakesEsolangs * (+145)
19:31:42 -!- impomatic has joined.
19:37:43 -!- Lord_of_Life has quit (Ping timeout: 246 seconds).
19:37:53 -!- Lord_of_Life_ has joined.
19:39:13 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
19:39:37 <esolangs> [[USI]] https://esolangs.org/w/index.php?diff=172561&oldid=172558 * Yayimhere2(school) * (+65) /* Memory */
19:46:17 <esolangs> [[User talk:RaiseAfloppaFan3925]] https://esolangs.org/w/index.php?diff=172562&oldid=172011 * Frendoly * (+237)
19:47:42 <esolangs> [[User talk:RaiseAfloppaFan3925]] https://esolangs.org/w/index.php?diff=172563&oldid=172562 * Frendoly * (+131)
19:48:37 <esolangs> [[Countable]] M https://esolangs.org/w/index.php?diff=172564&oldid=172548 * Aadenboy * (-210) /* Commands */ simplifying language
19:49:54 <esolangs> [[User talk:RaiseAfloppaFan3925]] M https://esolangs.org/w/index.php?diff=172565&oldid=172563 * Frendoly * (-1)
19:56:59 <esolangs> [[Countable]] https://esolangs.org/w/index.php?diff=172566&oldid=172564 * Aadenboy * (+46) /* Commands */
20:18:23 -!- somefan has quit (Remote host closed the connection).
20:18:31 -!- somefan has joined.
20:21:24 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
20:22:41 -!- tromp has joined.
20:50:32 <esolangs> [[User talk:FluixMakesEsolangs/Secret]] M https://esolangs.org/w/index.php?diff=172567&oldid=172560 * Ractangle * (+206)
20:52:34 <esolangs> [[Talk:Pythong]] N https://esolangs.org/w/index.php?oldid=172568 * * (+88) Created page with "but what if you type print("garfield")?! the program would be incorrect 20% of the time!"
20:52:53 <esolangs> [[Talk:Pythong]] M https://esolangs.org/w/index.php?diff=172569&oldid=172568 * * (+0)
20:53:25 <esolangs> [[User talk:FluixMakesEsolangs/Secret]] https://esolangs.org/w/index.php?diff=172570&oldid=172567 * * (+19)
20:53:32 <esolangs> [[User:Blashyrkh/Crazy J]] M https://esolangs.org/w/index.php?diff=172571&oldid=172547 * Blashyrkh * (+14) Strike out few TODO entries
21:13:48 <esolangs> [[Special:Log/newusers]] create * 6S37l0314M0ri1109 * New user account
21:31:37 <esolangs> [[User:Hotcrystal0/Sandbox]] https://esolangs.org/w/index.php?diff=172572&oldid=172511 * Hotcrystal0 * (+54)
21:43:23 <esolangs> [[Backtick]] M https://esolangs.org/w/index.php?diff=172573&oldid=172401 * Splot-dev * (+458) Added why Backtick is Turing Complete.
21:44:02 <esolangs> [[Backtick]] M https://esolangs.org/w/index.php?diff=172574&oldid=172573 * Splot-dev * (+0) Moved link.
21:46:03 <esolangs> [[Backtick]] M https://esolangs.org/w/index.php?diff=172575&oldid=172574 * Splot-dev * (-1) fixed syntax
21:46:47 <esolangs> [[Backtick]] M https://esolangs.org/w/index.php?diff=172576&oldid=172575 * Splot-dev * (-1) moved comment to new line
21:47:10 <esolangs> [[Backtick]] M https://esolangs.org/w/index.php?diff=172577&oldid=172576 * Splot-dev * (+1) fixed grammar
22:04:02 -!- impomatic has quit (Quit: Client closed).
22:04:02 -!- somefan has quit (Remote host closed the connection).
22:04:12 -!- somefan has joined.
22:08:17 <esolangs> [[Language list]] M https://esolangs.org/w/index.php?diff=172578&oldid=172475 * Buckets * (+14) /* M */
22:08:48 <esolangs> [[User:Buckets]] M https://esolangs.org/w/index.php?diff=172579&oldid=172476 * Buckets * (+13)
22:09:02 <esolangs> [[Masheen]] N https://esolangs.org/w/index.php?oldid=172580 * Buckets * (+1064) Created page with "Masheen is an Esoteric Programming Language created by [[User:Buckets]] in 2022. The IP Will start at the top-Left pointing Rightwards. {| class="wikitable" |- ! Commands !! Instructions |- | m || Point downwards if The Current value Is Perfectly Divisible by m(, so it
22:40:38 -!- tromp has quit (Quit: My iMac has gone to sleep. ZZZzzz…).
23:12:16 -!- scoofy has quit (Ping timeout: 246 seconds).