I mean, why would I expect the parenthesised subtraction to do anything I can rely on? Or did you mean (&ys[2] - &ys[0]) ?
int zs[20] = {0};
int *xs = &zs[0], *ys = &zs[10];
Of course, any veteran C programmer will point at that being UB, but the big-array-of-bytes (with holes) model is what one sees in userspace assembly, and what I assume most systems programmers think about most of the time, rather than the C memory model.
I wouldn't recommend that someone trying to learn systems programming (as opposed to C or C++ as languages) spend, like, any time whatsoever memorizing the list of C UBs (and then learning about pointer provenance, exposed addresses, etc., I suppose?). Assembly, Forth, safe Go, and safe Rust don't have the same kind of UB, and (Linux) kernel C has a different set of UBs than userspace/spec-compliant C.
OP is asking about a language to learn. Let them fail, to learn and understand.
And after all, C was and actually is moving the world forward, and thanks to C you have the possibility to write and run programs in Rust. Rust can't do anything if not by calling C APIs. Removing C code from any system is removing the legs from the crab.
So why not choosing C? Seems wise to me. Think about the thousands of lines of C code executing across the world so you can just download a crate. It seems to me that your first interest, as a Rust user, is to have C programmers around so you can run your Rust code.
I'll contribute by telling my personal experience after 20 years of embedded and system C: the fear spread by Rustaceans (regarding UB) is uber-exaggerated, specially at learning stages.
Before you bring exploits up, not every C application is connected to internet or has a user interface or runs as root. Just a portion.
struct edge {
struct node* src;
int dst_offset;
int label;
};
Later, someone else changed how nodes were allocated, so adding a new node would never trigger a realloc of the whole graph. Instead, a linked list of node arrays is allocated. Suddenly now, computing dst_offset is UB, and yet, the observed behavior of the resulting program is the same.
Even later, someone updated GCC on the CI machine, and now the inliner is more aggressive. Suddenly, mutations to node labels are unreliable, and edges are found to not refer to any node in the graph, except when debug logging logs the address they actually refer to.
This is the kinda thing that requires an understanding of UB that has nothing to do with the actual hardware to diagnose and fix, which I think is really unnecessary for a beginner.