Robert Millan wrote:
> Ok then. But if I preallocate a buffer on the stack, then xctime() can't
> return it.
Of course it cannot return a pointer to an array in its own stack frame.
You want to write a function that executes strftime and returns its result
in freshly allocated memo
y limit, but rather a threshold
> below which the implementation is more efficient that above the threshold.
Ok then. But if I preallocate a buffer on the stack, then xctime() can't
return it. I suppose you want it to preallocate on heap?
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
Robert Millan wrote:
> > - In the average case, you can get away with 1 strftime call instead of 2,
> > if you preallocate a buffer on the stack:
> > char buf[256];
> > len = strftime (buf, sizeof (buf), "%c", loctime) + 1;
> > In the case where 256 bytes are not enough, the f
On Sun, Jan 24, 2010 at 08:51:58PM +0100, Bruno Haible wrote:
> Hmm, if this is proposed for gnulib, I have 4 remarks:
>
> - Error handling: strftime can fail. Since you call xmalloc for the
> memory allocation, I think it would be reasonable to call error()
> in case strftime fails.
Ok
Hi Robert,
Robert Millan wrote:
> I implemented xctime for GNU isofsmk. xctime is an alternative to ctime()
> that:
>
> - Uses dynamic allocation
> - Is thread-safe
> - Returns localized strings
I agree that it's not a good idea to use ctime() or asctime(),
Hi,
I implemented xctime for GNU isofsmk. xctime is an alternative to ctime()
that:
- Uses dynamic allocation
- Is thread-safe
- Returns localized strings
char *
xctime (const time_t *time)
{
struct tm *loctime;
char *str;
size_t len;
loctime = localtime (time);
len
