My responses are with regards to general use on x64/x86 architecture today, with gcc or clang. If this is for NES or some other architecture, I have no experience with cc65's compiler.
1. It depends. Neither is better or worse than the other. If you don't need the additional indirect addressing (2nd example), then don't use it. If you do plan on changing
mystru to point to a different allocated
STRU_T somewhere, then the 2nd example is a better choice. The 2nd example is also necessary if you need to dynamically allocate structures using
malloc/calloc and then referencing them (example: a linked list of structs).
2. You didn't declare
buffer. I'm going to assume you either were using
char buffer[8]; or
char *buffer; buffer = malloc(8);.
In either case:
memset is recommended. For small-ish buffers, however, allocating them on the heap is fine. For large-ish, always allocate dynamically, and use
calloc() if you know definitively the contents need to be zeroed.
If you're allocating it on the heap though, you could just do
char buffer[8] = {0}; to have it pre-allocated to zero by the linker/loader.
3. It depends, but going entirely off the example you gave, I would prefer the former. This question distantly reminds me of
char *argv[] vs.
char **argv; I always prefer the former.
If you're using clang/LLVM, and you're really concerned about performance (cycle counts) or size (number of instructions), then I strongly suggest using
-S -mllvm (and you might be interested in
--x86-asm-syntax=intel if you prefer Intel syntax; I do) then looking at the resulting
.s files. You might be very surprised the difference things like
-O vs.
-O2 vs.
-O3 vs.
-Os makes.
The reason I mention this: last month I saw the FreeBSD project
commit this. My reaction: "why are they using that temporary variable
t? They can do this without a temporary variable: just use the XOR swap method!" So I replaced their version with mine:
p[0] ^= p[1]; p[1] ^= p[0]; p[0] ^= p[1];. The result was slower and longer than using a temporary variable.
-O2 greatly helped but it was still longer. My point is that compilers sometimes generate code that a human writing assembly wouldn't. I generally trust compilers to make optimal decisions these days, but there are always cases where humans do better.