lifo/fifo: first word is not always first 4 bytes

[npitre]

The first word is used as a pointer, meaning it is 64 bits on 64-bit
systems. To reserve it, it has to be either a pointer or a long, not an
int nor an u32_t.

[ghost]

Why are we using explicit longs here instead of intptr_t?

[pfalcon]

I'd personally find "aligned on a word boundary" (without reference to a specific number of bytes) to be better, here and elsewhere. (Because in 20 years, kids will smile seeing such references from the dark ages of IT ;-) ).

[npitre]

On Mon, 24 Jun 2019, Charles E. Youse wrote: Why are we using explicit `long`s here instead of `intptr_t`?

No particular reason other that they all occupy the same space as a pointer. This could be void* just as well, and many places do that already. In some other cases you'll find sys_snode_t instead (which is inferring too much about the underlying purpose of that word IMHO). Personally I don't like the untyped data argument to the queue API that much, especially if the first word is special. I would have created some opaque type, say q_hook_t, to be embedded in whatever structure you want to queue. Something like: struct my data { q_hook_t q_hook; int whatever[12]; }; struct my_data foo = ...; And then you'd have to pass that using the q_hook address: k_fifo_put(fifo, &foo.q_hook); Then the queue implementation really becomes decoupled from its users. But as a first step, there could be only that dedicated type whose purpose is to reserve that first word and clearly indicate what interface it is for.

[ghost]

No particular reason other that they all occupy the same space as a pointer. This could be void* just as well, and many places do that already.

To continue our discussion from your other related PRs, let's just pick a consistent standard. If long makes you happy here, great, but let's stop using intptr_t in other contexts then.

Personally I don't like the untyped data argument to the queue API that
much, especially if the first word is special. I would have created some
opaque type, say q_hook_t, to be embedded in whatever structure you want
to queue.

There's an API meeting tomorrow at 8am PST (unsure where you are), this is a good idea and maybe you join and bring this to everyone's attention. It's a good point...

[ghost]

Settled my concerns about long/intptr_t etc.

[dbkinder]

doc changes LGTM, thanks.

[npitre]

On Mon, 24 Jun 2019, Paul Sokolovsky wrote: I'd personally find "aligned on a word boundary" (without reference to a specific number of bytes) to be better, here and elsewhere. (Because in 20 years, kids will smile seeing such references from the dark ages of IT ;-) ).

OK. I've removed most of them. I only kept the part in the doc where the total size is mentioned. Let's make it easy for Zephyr to be ported to quantum computers in 20 years. ;-)

[pfalcon]

To continue our discussion from your other related PRs, let's just pick a consistent standard. If long makes you happy here, great, but let's stop using intptr_t in other contexts then.

And we already had that discussion in #16559, and already chose (u)intptr_t to use, especially given that it's recommended by the C standard (at the very least, it was introduced in the standard for usages like this, from which I hope it's fair to say that the standard recommends it).

So let me kindly call for consistency (ideally in this and future PRs like this, as I get as reviewer only in subset of 64-bit support PRs).

[ghost]

So let me kindly call for consistency (ideally in this and future PRs like this, as I get as reviewer only in subset of 64-bit support PRs).

That's fine with me, as long as we're consistent. But @npitre did not appear to think this was settled, as this PR demonstrates.

[npitre]

OK. Back to intptr_t it is then. However, please someone merge #16645 as intptr_t is not consistently defined without it i.e. sometimes it is an int, sometimes it is a long, even when considering only 32-bit targets.

Code changed to uintptr_t

[pfalcon]

recheck