MastodonTech.de

Felix Palmen :freebsd: :c64:I recently took a dive into <a href="https://mastodon.bsd.cafe/tags/C11" class="mention hashtag" rel="nofollow noopener" target="_blank">#C11</a> <a href="https://mastodon.bsd.cafe/tags/atomics" class="mention hashtag" rel="nofollow noopener" target="_blank">#atomics</a> to come up with alternative queue implementations not requiring locking some <a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#mutex</a>.TBH, I have a hard time understanding the <a href="https://mastodon.bsd.cafe/tags/memory" class="mention hashtag" rel="nofollow noopener" target="_blank">#memory</a> <a href="https://mastodon.bsd.cafe/tags/ordering" class="mention hashtag" rel="nofollow noopener" target="_blank">#ordering</a> constraints defined by C11. I mean, I code <a href="https://mastodon.bsd.cafe/tags/assembler" class="mention hashtag" rel="nofollow noopener" target="_blank">#assembler</a> on a <a href="https://mastodon.bsd.cafe/tags/mos6502" class="mention hashtag" rel="nofollow noopener" target="_blank">#mos6502</a> (for the <a href="https://mastodon.bsd.cafe/tags/c64" class="mention hashtag" rel="nofollow noopener" target="_blank">#c64</a>), so caches, pipelines and all that modern crap is kind of alien rocket science anyways 😆.But seriously, they try to abstract from what the hardware provides (different kinds of memory barrier instructions, IMHO somewhat easier to understand), so the compiler can pick the appropriate one depending on the target CPU. But wrapping your head around their definition really hurts the brain 🙈.Yesterday, I found a source telling me that <a href="https://mastodon.bsd.cafe/tags/amd64" class="mention hashtag" rel="nofollow noopener" target="_blank">#amd64</a> (or <a href="https://mastodon.bsd.cafe/tags/x86" class="mention hashtag" rel="nofollow noopener" target="_blank">#x86</a> in general?) always has strong ordering for reads, so no matter which oderding constraint you put in your atomic_load and friends, the compiler will generate the same code and it will work. Oh boy, how should I ever verify my code works on e.g. aarch64 without owning such hardware?

Felix Palmen :freebsd: :c64:Hm, is <a href="https://mastodon.bsd.cafe/tags/valgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#valgrind</a>'s <a href="https://mastodon.bsd.cafe/tags/helgrind" class="mention hashtag" rel="nofollow noopener" target="_blank">#helgrind</a> useless for code using <a href="https://mastodon.bsd.cafe/tags/atomic" class="mention hashtag" rel="nofollow noopener" target="_blank">#atomic</a> operations? Example, it complains about this:==9505== Possible data race during read of size 4 at 0xADD57F4 by thread #14 ==9505== Locks held: none ==9505== at 0x23D0F1: PSC_ThreadPool_cancel (threadpool.c:761) [....] ==9505== This conflicts with a previous write of size 4 by thread #6 ==9505== Locks held: none ==9505== at 0x23CDDE: worker (threadpool.c:373)so, here's threadpool.c:761: if ((pthrno = atomic_load_explicit( &job->pthrno, memory_order_consume)) >= 0)and here's threadpool.c:373: atomic_store_explicit(&currentJob->pthrno, -1, memory_order_release);Ok, I *think* this should be fine? Do I miss something?(screenshots for readability ...)<a href="https://mastodon.bsd.cafe/tags/c" class="mention hashtag" rel="nofollow noopener" target="_blank">#c</a> <a href="https://mastodon.bsd.cafe/tags/coding" class="mention hashtag" rel="nofollow noopener" target="_blank">#coding</a> <a href="https://mastodon.bsd.cafe/tags/c11" class="mention hashtag" rel="nofollow noopener" target="_blank">#c11</a> <a href="https://mastodon.bsd.cafe/tags/atomics" class="mention hashtag" rel="nofollow noopener" target="_blank">#atomics</a>

Felix Palmen :freebsd: :c64:Next <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#swad</a> improvement: Make sure to <a href="https://mastodon.bsd.cafe/tags/wipe" class="mention hashtag" rel="nofollow noopener" target="_blank">#wipe</a> <a href="https://mastodon.bsd.cafe/tags/passwords" class="mention hashtag" rel="nofollow noopener" target="_blank">#passwords</a> from RAM directly after used. That's more of a <a href="https://mastodon.bsd.cafe/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#security</a> precaution, because there *should* be no way how an attacker can access a running process' memory, but you never know which bugs surface 🙈.Unexpectedly, that posed <a href="https://mastodon.bsd.cafe/tags/portability" class="mention hashtag" rel="nofollow noopener" target="_blank">#portability</a> issues. <a href="https://mastodon.bsd.cafe/tags/C11" class="mention hashtag" rel="nofollow noopener" target="_blank">#C11</a> has <a href="https://mastodon.bsd.cafe/tags/memset_s" class="mention hashtag" rel="nofollow noopener" target="_blank">#memset_s</a> ... a pretty weird function, but suitable for wiping. It's there on <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#FreeBSD</a> and on <a href="https://mastodon.bsd.cafe/tags/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#OpenBSD</a>. Not on <a href="https://mastodon.bsd.cafe/tags/NetBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#NetBSD</a> though. But NetBSD offers the much saner <a href="https://mastodon.bsd.cafe/tags/C23" class="mention hashtag" rel="nofollow noopener" target="_blank">#C23</a> function <a href="https://mastodon.bsd.cafe/tags/memset_explicit" class="mention hashtag" rel="nofollow noopener" target="_blank">#memset_explicit</a>. Looking at <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#Linux</a>, there's neither. But there is the (non-standard!) <a href="https://mastodon.bsd.cafe/tags/explicit_bzero" class="mention hashtag" rel="nofollow noopener" target="_blank">#explicit_bzero</a> 🤯 .. and with glibc, it requires _DEFAULT_SOURCE to be defined as soon as you compile with a C standard version given to the compiler. This function exists on some other systems as well, but there's confusion whether it should be declared in string.h or strings.h. 🤪 Here's the full set of compile-tests I'm now doing, only to find the best way to really erase memory: <a href="https://github.com/Zirias/swad/blob/master/src/bin/swad/swad.mk#L6" rel="nofollow noopener" translate="no" target="_blank">https://github.com/Zirias/swad/blob/master/src/bin/swad/swad.mk#L6</a>And if none of these functions is found, swad uses the "hacky" way that most likely works as well: Access the normal memset function via a volatile pointer.

Tyler SmithAndrew Coyne very clearly articulates why the Canadian goverment's <a href="https://ottawa.place/tags/C11" class="mention hashtag" rel="nofollow noopener" target="_blank">#C11</a> <a href="https://ottawa.place/tags/LinkTax" class="mention hashtag" rel="nofollow noopener" target="_blank">#LinkTax</a> and <a href="https://ottawa.place/tags/C18" class="mention hashtag" rel="nofollow noopener" target="_blank">#C18</a> internet <a href="https://ottawa.place/tags/CanCon" class="mention hashtag" rel="nofollow noopener" target="_blank">#CanCon</a> bills are actively harmful to Canadians and our access to <a href="https://ottawa.place/tags/journalism" class="mention hashtag" rel="nofollow noopener" target="_blank">#journalism</a> and the <a href="https://ottawa.place/tags/internet" class="mention hashtag" rel="nofollow noopener" target="_blank">#internet</a> generally. Certainly we have challenges to face on these issues, but a good start would be not making things worse with misguided and heavy-handed regulations <a href="https://www.theglobeandmail.com/opinion/article-the-government-dug-a-deep-hole-for-itself-with-bills-c-11-and-c-18-and/" rel="nofollow noopener" target="_blank">https://www.theglobeandmail.com/opinion/article-the-government-dug-a-deep-hole-for-itself-with-bills-c-11-and-c-18-and/</a><a href="https://ottawa.place/tags/paywall" class="mention hashtag" rel="nofollow noopener" target="_blank">#paywall</a>

Michael GeistCRTC establishes new registration requirements arising from Bill C-11 for streaming services worldwide, including video and podcasters. Any service - alone or as a group - generating $10M+ in broadcast revenues in Canada must register by November 29, 2023. <a href="https://twitter.com/CRTCeng/status/1707818973880823935" rel="nofollow noopener" translate="no" target="_blank">https://twitter.com/CRTCeng/status/1707818973880823935</a><a href="https://mas.to/tags/C11" class="mention hashtag" rel="nofollow noopener" target="_blank">#C11</a>

Senator Paula Simons🇨🇦I also care in all kinds of crazy ways about communications policy. I have an MA in Communication from <a href="https://mstdn.ca/tags/Stanford" class="mention hashtag" rel="nofollow noopener" target="_blank">#Stanford</a>, and I spent 30 years as a working journalist, with the <a href="https://mstdn.ca/tags/CBC" class="mention hashtag" rel="nofollow noopener" target="_blank">#CBC</a> and <a href="https://mstdn.ca/tags/Postmedia" class="mention hashtag" rel="nofollow noopener" target="_blank">#Postmedia</a> among others. As a member the Transportation and Communications committee (aka <a href="https://mstdn.ca/tags/TRCM" class="mention hashtag" rel="nofollow noopener" target="_blank">#TRCM</a>) I work on comms policy of all sorts, including the controversial <a href="https://mstdn.ca/tags/C11" class="mention hashtag" rel="nofollow noopener" target="_blank">#C11</a> <a href="https://mstdn.ca/tags/C18" class="mention hashtag" rel="nofollow noopener" target="_blank">#C18</a> and the issues involving <a href="https://mstdn.ca/tags/Meta" class="mention hashtag" rel="nofollow noopener" target="_blank">#Meta</a> <a href="https://mstdn.ca/tags/Facebook" class="mention hashtag" rel="nofollow noopener" target="_blank">#Facebook</a> <a href="https://mstdn.ca/tags/Google" class="mention hashtag" rel="nofollow noopener" target="_blank">#Google</a> <a href="https://mstdn.ca/tags/Alphabet" class="mention hashtag" rel="nofollow noopener" target="_blank">#Alphabet</a> etc. So if you are a comms policy wonk, please let's connect! <a href="https://mstdn.ca/tags/introduction" class="mention hashtag" rel="nofollow noopener" target="_blank">#introduction</a> <a href="https://mstdn.ca/tags/journalism" class="mention hashtag" rel="nofollow noopener" target="_blank">#journalism</a>

BrandonLooking forward to only being able to get news only from authorized Canadian news sources, because Canadian news outlets are so trustworthy. So good for democracy and freedom of information! <a href="https://appdot.net/tags/cdnpoli" class="mention hashtag" rel="nofollow noopener" target="_blank">#cdnpoli</a> <a href="https://appdot.net/tags/c11" class="mention hashtag" rel="nofollow noopener" target="_blank">#c11</a> <a href="https://appdot.net/tags/billc11" class="mention hashtag" rel="nofollow noopener" target="_blank">#billc11</a> <a href="https://appdot.net/tags/Canada" class="mention hashtag" rel="nofollow noopener" target="_blank">#Canada</a>

Michael GeistThis post is supportive of Bill C-11 but the examples demonstrate the problems. Do we really want the CRTC parsing through user content feeds to decide the kind of content people get: a bit more French music, hands off home renovation videos, etc? --- RT @howardalaw The never ending ambiguity of the Online Streaming Act <a href="https://mas.to/tags/C11" class="mention hashtag" rel="nofollow noopener" target="_blank">#C11</a>. What the <a href="https://mas.to/tags/CRTC" class="mention hashtag" rel="nofollow noopener" target="_blank">#CRTC</a> might do about discoverability.<a href="https://mediapolicy.ca/2023/04/28/the-never-ending-ambiguity-of…" rel="nofollow noopener" target="_blank">https://mediapolicy.ca/2023/04/28/the-never-ending-ambiguity-of…</a> <a href="https://twitter.com/howardalaw/status/1651940097015554056" rel="nofollow noopener" target="_blank">https://twitter.com/howardalaw/status/1651940097015554056</a>

Frühere Suchanfragen

Suchoptionen

Verwaltet von:

Serverstatistik:

#C11