On Mon, Jan 11, 2010 at 1:14 PM, Raphael Neider <rneider@web.de> wrote:

> I *will* code the time functions and contribute them, because I need
> them:
> -asctime
> -difftime
> -probably also time_t / struct tm conversions
> How should I proceed? Write the in the lib/src/pic16 directory, then
> update the makefiles? (then send a patch, ok)

Yepp, that would be a viable option. Please update
device/lib/pic16/libc/Makefile.am rather than any Makefile{,.in} directly.
Then add your patch to the sdcc patch tracker at
http://sourceforge.net/tracker/?group_id=599&atid=300599 .

I just tried to simply add ../../time.c to the SOURCES in
device/lib/pic16/libc/Makefile.am, but the pic16 port seems to choke on
initialized arrays of string literals. I will have to look into that, but
in the meantime, you could contribute a variant of ../../time.c (and
probably time.h) for the pic16 port.

the choking code may be the _CODE keyword:
_CODE const char * _CODE __month[]={"Jan", .....

Is it required? isn't "const" sufficient to make this a code stored array?

a simple #ifdef can remove the offending keywords.

> Can I copy code from the file I indicated in my previous mail?

Yes, of course. Please express your consent to apply the GPL+LE license
) to your contribution, as that license seems to be what all past and
current developers can accept.

> Do we need special performant code for asctime & al?

I would not think so.

So I will avoid an assembly version :)

> what about sprintf? (ok, I can/will probably) use basic string copy
> operations here - do we have a working itoa? )

sprintf() *is* available for the pic16 port, just include stdio.h

and be
happy. If you link manually, you must add libc18f.{a,lib} to the list of
linked libraries (but you knew that already).

what is "manual linking"? I think I'm not linking manually when I call "sdcc" without the -c option. I did not call directly the ld binary.