Re: [avr-libc-dev] Documentation/Lib mismatch for inverse( ) function in math lib?

[Joerg Wunsch]

As Wouter van Gulik wrote:

> Aha, but by accident it was exported to documentation. That's clear
> for me now.

I think it used to be exported to documentation on purpose once, but I
didn't notice that detail when I renamed all supposedly internal
functions, and silently assumed inverse() to be of only internal
importance.

Are there any other opinions about exporting it?  There's now
obviously at least a single user who wants to use it, so exporting it
might make sense.  OTOH, names like square() and inverse() pollute the
application's namespace, and thus risk to collide with an otherwise
standard-conforming application.  This kind of collision is OK for
header files that are specific to avr-libc, but for <math.h>, I'd
rather like to avoid it.  Sure, we do have other examples like
dtostre() and dtostrf(), but personally I believe they are in much
lower collision risk than square() and inverse().

So what to do?  Bracket square() and inverse() into some

#ifdef _USING_AVR_LIBC_EXTENSIONS
...
#endif

macro?  That's usually the take operating systems vendors chose for
their public header files.  It would require another macro though that
needs to be published and documented.

Export them as _square() and _inverse()?  That way, they are in the
implementation name space, thus cannot collide with the application.
This approach appears to be not that uncommon in particular in the
embedded world.  We already do it ourselves with the _BV() macro,
other compilers use that extensively (like _SEI(), _NOP(), ...).  From
an esthetical point of view, I don't particularly like exporting
symbols that start with an underscore, but then, we've already done
that for _BV() anyway.

[Arguments with __x]

> >So yes, this is a bug.  However, its resolution depends on whether
> >we are going to withdraw the function inverse() from public
> >namespace alltoghether or not.

> Shall I fill in a bug report, so this issue will not be forgotten?

Yes, please do.

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

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