Hi Mike, With avr-libc, where the functions are implementing some standard, we try to adhere to that standard.
There are Standard C library functions. Users know this and don't create functions that collide with the Standard C library. If someone includes <time.h> (or <avr/time.h, as the case may be), then they should expect that the time API is available and they shouldn't create functions that collide with it. We should not have to create a configuration switch --without-time, because that also implies we should create a configuration switch for every single API grouping in avr-libc; that's just ridiculous. Same with prefixing all the functions; again that's ridiculous because most of them are Standard C functions that have standard names anyway. I'll be the first to admit that I'm not that familiar with various time API standards. Is there a particular standard that you're implementing? If so, that should basically inform you, and the users, how to implement and use it the best. HTH, Eric > -----Original Message----- > From: avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org] On > Behalf Of Michael Rice > Sent: Wednesday, March 27, 2013 2:54 PM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] Time library > > A question has arisen about the possibility of 'collisions' of > application defined functions, with the avr-libc time functions. > > Is this something we should worry about? Personally I do not think it > will be an important issue, but I would like to have the opinion of > the developers. > > I spent some time on Google, searching various combinations of time, > time.h, atmel, avr, atmega, time(), time_t and mktime(). I did not > find much, mostly complaints that time.h is not implemented in avr- > libc.: { > > My personal ( read: biased! ) opinion is to implement time.h more or > less as-is, and provide a configuration switch, --without-time perhaps. > > Another palliative may be to split time.h into ephemera.h, > time_extras.h, and time.h... or something along those lines. > > A third palliative is to prefix all our functions, for example with > avr_. I really don't like that one. > > I would like to hear the opinion of others on this issue, perhaps some > has a better solution. > > === > > In other news, I have rearranged some things, added copyright and $ID > $to each file, and have a good start on the Doxygen stuff, its really > going faster than what I expected! > > > _______________________________________________ > AVR-libc-dev mailing list > AVR-libc-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/avr-libc-dev _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
