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. ;-) _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
