c - How to test the rules of undefined behavior in respect to sequence point? -

i reading ub 2 days , confusion growing in mind following example

int a=5; a++ & printf("%d",a);//i know `&` introduced here not sequence point. 

now,it ub in c looking @ different angel following

now c standard says

between previous , next sequence point object shall have stored value modified @ once evaluation of expression.

so,as modifying value of writing a++ once,this rule fails in declaring behavior ub.
further states

furthermore, prior value shall accessed determine value stored.

as prior value of a ( 5 here ) accessed via a++ write value of a .but in statement printf("%d",a)

("%d",a) full expression.so all dust of side effect should settled down before expression runs.
according standard

when function call made there sequence point before actual call , after evaluation of arguments.

so a should have been modified here in function call,more precise value of a updated according standard.
why yet ub ("%d",a) expression in , evaluated before ;?

the expression a++ & printf("%d",a) contains 5 interesting steps:

• a) read a
• b) increment a
• c) read a
• d) call printf
• e) bitwise-and

you may expect c++ execute these steps top bottom (a->b->c->d->e), because humans tend read left right. in fact, c++ gives following guarantees:

• a executed before b (a->b)
• c executed before d (c->d), because functions need know arguments
• a , d executed before e (a->e, d->e), because operators need know operands
• if executed before d (a->d), b executed before d (b->d), because a++ has side effect, function calls sequence points, , side effects guaranteed visible then.

note there no guarantee of form (a->c) or (b->c). beginners don't get.

does c read value before or after increment happens @ b? not know!

• the operator & not impose restrictions on order of evaluation of operands, second operand printf("%d",a) may evaluated before first operand a++. (the evaluations of operands may interleaved, long obey above guarantees.)
• even if first operand evaluated before second operand, side effect happens in b not guaranteed visible when c executed. (it would visible @ d then, because function calls sequence points, it's late. arguments have been evaluated.)

these restrictions leave following possible execution orders:

• a->b->c->d->e
• a->c->b->d->e
• c->a->b->d->e
• c->d->a->b->e
• c->a->b->d->e

it took me several attempts write list down. not 100% correct , complete.