c - GCC __atomic functions: _n suffix vs explicit width, e.g. _4 -


the gcc __atomic api has multiple functions ending in _n, e.g.

__atomic_load_n  __atomic_store_n 

the compiler supports intrinsitcs n replaced 1, 2, 4, 8 or 16 (which have infer exist docs - imo docs pretty hazy __atomics , should improved!). when explicit number used tells compiler width of data atomic operation should operate on. when _n used i'm presuming compiler infers width type passed if can, or errors otherwise.

i checked last statement passing void* __atomic_load_n , complained, wasn't big surprise.

so questions are:

  • is have said correct?
  • is there reason not use _n version except in case have opaque pointer , need explicitly tell compiler how wide it's pointee is?
  • are there other subtleties i'm missing stuff?

thanks


Comments

Popular posts from this blog

html - Outlook 2010 Anchor (url/address/link) -

javascript - Why does running this loop 9 times take 100x longer than running it 8 times? -

Getting gateway time-out Rails app with Nginx + Puma running on Digital Ocean -