Re: [avr-libc-dev] Time library

[Weddington, Eric]

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: address@hidden
> [mailto:address@hidden On
> Behalf Of Michael Rice
> Sent: Wednesday, March 27, 2013 2:54 PM
> To: address@hidden
> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-libc-dev