Point is: as retiredfeline said, the "&" here can't be an infix, binary operator in this context, because (uint32_t *) is not a valid left value for such an operator. But for that to be true, the compiler has to know (uint32_t *) is a cast and not a valid value.
More than that, the compiler has to know that "uint32_t *" is a type, which means it has to know that "uint32_t" is a type.
int uint32_t = 42;
pSrc = (uint32_t *) & _sfixed
In this case, "(uint32_t *)" has to be a syntax error as the multiply has no right hand operand.
It is one of the big warts in C syntax that the parser must have access to the symbol table to understand many constructs. And the human programmer also.
Point is: as retiredfeline said, the "&" here can't be an infix, binary operator in this context, because (uint32_t *) is not a valid left value for such an operator. But for that to be true, the compiler has to know (uint32_t *) is a cast and not a valid value.
More than that, the compiler has to know that "uint32_t *" is a type, which means it has to know that "uint32_t" is a type.
int uint32_t = 42;
pSrc = (uint32_t *) & _sfixed
In this case, "(uint32_t *)" has to be a syntax error as the multiply has no right hand operand.
It is one of the big warts in C syntax that the parser must have access to the symbol table to understand many constructs. And the human programmer also.
This definitely reminds us of this earlier thread with a small "fight" about parsing C.
One thing that it shows in both cases is that a "proper" (read: "ok for general use") C parser must be "biased" towards assuming the source code it parses IS correct, meaning if there could be any "doubt", it must prioritize correct constructs over potential syntax errors. Otherwise there would be so many potentially erroneous constructs that programming in C would be a living hell.
In this example, we haven't even explored all possible interpretations:
In "(uint32_t *) & _sfixed", as you said, the "*" operator *could* be a multiply. Sure as you said, as it has a type as a left-hand operand, and no right-hand operand, it' s more likely to be the type expression "uint32_t *". But it's all in this: "more likely". For all you know, it could be a double mistake from the programmer, who might have meant a multiply, with one bogus operand and one missing operand. Here, if you don't have access to the symbol table, you may still choose to assume "uint32_t" is a type - as anything else would make the expression invalid - and check if it really is later on.
This bias is similar to the problem we saw in this other thread (with hex constants), so there must be a priority for possibly correct constructs over possible syntax errors. And yes, it's again not nearly as easy as it may seem.