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

[Paul Schlie]

actually it need not exist at all, if required it's intended to be defined
as a built-in within gcc.


> From: Joerg Wunsch <address@hidden>
> Reply-To: Joerg Wunsch <address@hidden>
> Date: Thu, 20 Oct 2005 07:01:09 +0200
> To: <address@hidden>
> Subject: Re: [avr-libc-dev] What is the necessity of _FFS() ?
> 
> 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. ;-)
> 
> 
> 
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev