Re: [avr-libc-dev] What is the necessity of _FFS() ?

[Joerg Wunsch]

As Dmitry K. wrote:

> What is the reason of '_FFS' appearance in the last Avr-libc CVS?

ffs() is a function, and should remain a function.  It violates the
principle of least astonishment (POLA) to suddenly have a macro by
that name that does magic things on its arguments -- among them,
evaluating its argument at least twice.  Think about people who'd
innocently do something like

...
   i = ffs(getsomevalue());
...

or even worse:

   i = ffs(rand());

(where rand() clearly returns a different value for each call).

Sure, you could always work around that by #undef'ing ffs in that
case, but see above: POLA.  Any other known implementation of ffs()
doesn't behave that way, so anybody who sees in the documentation that
we do implement ffs() has a good right to assume we implement it the
same way as anybody else.

I've then asked Anatoly what's the purpose of the macro implementation
at all, and he passed me your opinion on about having something like a
counterpart to _BV().  While I don't think _FFS has the same
importance as _BV (mainly since Atmel went the way to have all values
that would traditionally be expressed as a bit mask only around as a
bit number, so you only need the bit number -> bit mask computation),
I accepted that the counterpart of _BV might be a good idea, even
though it's an off-by-one counterpart (_BV starts numbering bits at 0,
_FFS starts numbering bits at one, in line with the ffs() function).

Naming convention demands that all function-like macros that have side
effects (like evaluating their argument more than once) are written in
all upper-case letters (*), so that made FFS.  In order to not pollute
the application namespace even more, I then also prepended the same
underscore we've already got in _BV.

(*) Historical exceptions are getc and putc, but for them, it has
always been clearly stated they might be implemented as macros that
evaluate their argument more than once (even though they aren't in our
case, as our stdio does no buffering).

As for the purpose of have a bit mask -> bit number computation that
works on constant expressions though, I then decided it doesn't make
sense to have this `automagic' fallback to ffs().  After all, the
programmer reasonably ought to know whether his argument is
compile-time constant or not.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)