ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
mattyinterrupt[m has quit [Quit: Idle timeout reached: 172800s]
Artea has quit [Ping timeout: 246 seconds]
Artea has joined #rust-embedded
rmsyn[m] has joined #rust-embedded
<rmsyn[m]> burrbull: so, I tried a bit of an experiment manually splitting out the peripheral modules into crates.... (full message at <https://catircservices.org/_irc/v1/media/download/AVUhClu1TcH6u3ytBDAMPhpdKo88NkPE4MYqXsZs92CcIoTxaya8JMTnp2PzLzYQdKv4wIOdEvmZu7ZLdkMvLmC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9mYXN6YnJ0eEZsRVlOT1FJcXpKY09QeUM>)
pbsds3 has quit [Quit: Ping timeout (120 seconds)]
pbsds3 has joined #rust-embedded
m5zs7k has quit [Quit: m5zs7k]
m5zs7k has joined #rust-embedded
pbsds3 has quit [Ping timeout: 245 seconds]
pbsds35 has joined #rust-embedded
<dinkelhacker> Hey, just noticed that ptr::write_bytes has a null check. On my platform 0x0 is a valid address. What would be a memset equivalent in rust that doesn't do any checks?
M9names[m] has joined #rust-embedded
<M9names[m]> probably safest to write that in asm yourself i think? how often do you expect to have to write to 0x0?
whitequark[cis] has joined #rust-embedded
<whitequark[cis]> i would probably just permanently allocate a byte or word at 0x0 so that you never have to think about it again
<dinkelhacker> Only once.. I'm relocating the vector table to there. Just wondered why there is no drop in replacement for memset that just writes wherever.
<thejpster[m]> Because it’s UB to write to the null pointer. You have to do it in assembly.
<thejpster[m]> We had a similar argument about a structure that lived at the top 16 bytes of address space.
<thejpster[m]> Ralf Jung had some strident opinions.
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]> If you already have memory to memory dma in your project / platform, use that instead of writing inline assembly for all CPU architectures you want to support ;-)
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> DMA varies more across chips than arch :P
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<ruabmbua[m]> <dirbaio[m]> "DMA varies more across chips..." <- Probably true 😂
<ruabmbua[m]> Worked out for my project, but not necessarily in most others 😬
<dinkelhacker> I just ended up using a good old for loop and ptr.offset to relocate the vector table. Probably not the fastest option but I don't care about that currently. At least it doesn't complain about UB. Allthough, it's probably still UB, right thejpster[m] ?
<thejpster[m]> Does it work in debug profile builds where the pointer validity assets are enabled?
dngrs[m] has joined #rust-embedded
<dngrs[m]> <judge[m]> "Hey guys … any recommendations..." <- https://docs.rs/picoserve/latest/picoserve/
<dngrs[m]> <thejpster[m]> "Because it’s UB to write to..." <- Does rust assume null == 0x0? C doesn't
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> a 0 can be a null pointer but a null pointer is not automatically 0x00. E.g a Null pointer is not comparable to any other null pointer
<vollbrecht[m]> so talking equality and general null pointers is nothing you can say in a general case
<vollbrecht[m]> * so talking equality and the concept of a general null pointers is nothing mush together
<vollbrecht[m]> * so talking equality to a specific value and the concept of a general null pointers is nothing mush together
<vollbrecht[m]> * so talking equality to a specific value and the concept of a general null pointers is nothing one can mush together
<dngrs[m]> (to classify, I was using == as a shorthand for "is at", not so much talking about actual equally ops)
lulf[m] has joined #rust-embedded
<lulf[m]> <realroot[m]1> "lulf how is going watchful..." <- You can try watchful using the builtin pinetime bootloader now. Only in trial mode, so once it resets, it will revert to infinitime again.
<dngrs[m]> s/classify/clarify/
almindor[m] has joined #rust-embedded
<almindor[m]> Not sure if this was mentioned but wrt. null pointers https://purplesyringa.moe/blog/falsehoods-programmers-believe-about-null-pointers/
<JamesMunns[m]> <dngrs[m]> "Does rust assume null == 0x0..." <- Rust does assume null is 0x0, afaik
<thejpster[m]> <dngrs[m]> "Does rust assume null == 0x0..." <- Yes. https://doc.rust-lang.org/std/ptr/fn.null.html
<thejpster[m]> The only machines that didn’t allow you to memset(&p, 0, sizeof(p)) were a couple of weird 70s mainframes that aren’t relevant today.
SirWoodyHackswel has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]> wasn't it also DPMI?
<whitequark[cis]> * also DPMI? (also not relevant today)
<whitequark[cis]> i'm not actually sure, i've just heard that to be the case; searching for it today it seems like the answer might be no
bitts[m] has quit [Quit: Idle timeout reached: 172800s]
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
SanchayanMaity has quit [Ping timeout: 248 seconds]
nohit has quit [Ping timeout: 248 seconds]
SanchayanMaity has joined #rust-embedded
nohit has joined #rust-embedded
<dinkelhacker> thejpster[m]: yepp looks like.. Actually I would have assumed that .offset would also complain about the address beeing 0x0.
ni has quit [Quit: WeeChat 3.8]
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
d3zd3z[m] has quit [Quit: Idle timeout reached: 172800s]
ni has joined #rust-embedded