John S

@PythonPr The version of python running. Python3 vs Python2?

What is the Difference 🤔 Comment The Difference 🤔❓

@raysan5 I might be mistaken, but this does not seem like a difference in compilers issue? The difference would be in what data "randomly" exists beyond the str02 calloc memory block that is allocated. That could be due to different lib implementations of calloc, or even just different libs being linked to / loaded at run time. I.e. maybe some libs that use calloc on init/load prior to main and change the runtime state of the allocator.

Why C compilers can't agree in how a standard C library function should works? ☹️ And better not to talk about strncpy()...

@rebane2001 They are actually in RAX, RCX, RDX, RBX order in the AMD Zen microcode too. 😱😱😱 #L92" target="_blank" rel="nofollow noopener">github.com/google/securit…

why is everybody gaslighting me into thinking the registers go RAX RBX RCX RDX?? they obviously go RAX RCX RDX RBX ???????? im going crazy why is nobody saying anything?? do people even read the instructions they write??

@SebAaltonen C++ exceptions are really not something anyone should actually use in a critical component (or maybe almost ever). Next thing you know, some jr dev will be throwing from inside constructor of a partially initialized class 😬😬😬.

Errors should be handled before you put data in the data structure. Low level processing functions should not fail. They don't know how to handle the failure. Process failures when bad data can enter the system instead. Simpler and more efficient.

Exceptions were a big design mistake. Hidden gotos all over the code base. Not easy to write "Strong Exception Safe" code. Rust returns error codes just like C. Wrapped in syntactic sugar. Return type can be error or actual type. Much nicer design.

@stylewarning Using C++ exceptions???? No no no no... just don't.

I'm overhearing a FAANG tech meeting about how this 10?-year product written in C is being transitioned ("modernized") to C++. Started by changing to a C++ compiler, and slowly rewriting to use classes/exceptions, &c. It's been 3 months, and the C++ service keeps failing in prod.

The interesting thing about this is the scope/lifetime of the __restrict__ annotated variable. If s_scores has the __restrict__ keyword then it extends accross the sync barriers. I would think that if all of the __restrict__ variables/ptrs went out of scope before the readback then you would get the behavior you wanted. Basically if you removed __restrict__ from s_scores and instead added additonal scoping that separates the writes from the readback after the sync and then in each of those sections use a temporary annoted __restrict__ pointer... But I'm not 100% sure.

Spent hours debugging a CUDA kernel that produced correct results in an isolated test but wrong output when __forceinline__-d into a larger kernel. Same code, same inputs, different results. The root cause is nvcc -O3 was silently eliminating a shared memory read-back. The compiler sees that thread x wrote my_score to s_scores[x], and then reads it back. With __restrict__ on the pointer and -O3, it concludes the load is redundant and forwards the register value instead. It doesn't account for thread x_else writing to the same address through the same pointer between the two __syncthreads() barriers. In the small test kernel the optimizer wasn't aggressive enough to apply this. In the full kernel with deep inlining, it was. The fix was structural, not annotation-based. Instead of interleaving register-resident and shared-memory-resident data flow in the same loop body, I separated them into distinct phases with explicit load/store boundaries. The compiler can't eliminate a read-back that doesn't exist.

@Adriksh I would recommend putting your head and tail on separate indepenent cache lines. There is a bunch of false sharing with the read only params of the struct.

Lock-free ring buffer in the C language. The buffer size is a power of two, so index wrapping uses a bitmask instead of modulo. Head and tail are atomic, allowing a single producer and consumer without locks. Common in logging, audio, and networking.

Aside from the non portability issues. You often end up with other performance issues related to the compiler trying to break up the bitfield reads and writes in strange ways that end up being inneficient. Treating it as a good old fashioned 32bit bitmask is usually the way to go. Additionally as the programmer you have additional context into how the memory might be addressed by other threads concurrently (part of the issues on why the comiler does wierd stuff to begin with). The bitmask approach ends up just being more efficient and portable.

Stop wasting bytes on boolean flags C has a super clean way to pack them super tight using bit fields – perfect for flags, status registers, protocol headers, or anything where every bit counts. Instead of using 4 separate ints you can squeeze 32 flags into just 4 bytes! Just watch out: padding & layout are implementation-defined - test on target.

Great presentation, this was really helpful! I have been playing around with Entrysign for a few months now. Using IBS was a game changer. Fwiw there is actually an easy way you can enable rdmsr/wrmsr instructions in ring3 once you already have ucode access. You can pretty much just write an IBS poller entirely in usermode wrapped around the code you want to trace at that point. I was eventually able to leak the xtea key using this method. Still trying to find a way to extract the rom contents. I think I have a good lead on it, but lack the proper setup. Let me know if you want to collab.

The recording of our OffensiveCon presentation about EntrySign is live! youtu.be/sUFDKTaCQEk Slides at entrysign.top @sirdarckcat @__spq__

@Istvan_A_Seres @lavados @misc0110 "-mbranch-cost=5" is your friend on gcc.

✅ Write constant-time crypto code ☠️ Compiler introduces timing side-channels Do Compilers Break Constant-time Guarantees? fc25.ifca.ai/preproceedings… TL;DR: Yes!🥲 👏👏👏Great work @misc0110 & team!

BREAKING: NORAD confirms 'high-altitude airborne object' flying over northern Canada fxn.ws/3lvXnt3