[M3devel] time.h reentrancy?

[Jay K]

My plan here is roughly:

 

 

copy Utime.i3 to UtimeInternal.i3.

  Keeping only functions that traffic in struct_tm.

In Utime.i3 define a struct_tm that doesn't have tm_zone and tm_gmtoff.

UtimeInternal.i3 define a struct_tm that does include tm_zone and tm_gmtoff.

Provide UtimeInternal.i3 only on platforms that use DateBsd.m3.

 

 

Utime.i3 will therefore be portable.

 

 

Both of them will be implemented via copying wrappers though,

since the order of the fields, and the exact size of the struct, is not portable.

 

 

Probably as well only the *_r functions should be provided?

Not clear, since the non *_r functions have optional extra side affects such as setting tznzme.

Probably keep the non *_r functions but callers must know to (maybe) serialize them.

  As DatePosix.m3/DateBsd.m3 do.

I think most libc implementations use thread locals here, so the need to serialize is nearly zero.

However there are user threads and timezone/daylight/tzname to worry about, not sure

they are thread locals, or only the "direct result buffers".

 

This area is really a mess.

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 20 Sep 2009 22:28:21 +0000
Subject: [M3devel] time.h reentrancy?



Does anyone understand how the time.h *_r functions are supposed to behave wrt the char* tm_zone field in struct tm?
This interface seems broken.
Posix doesn't include the tm_zone field, so it is self-consistent.
 
I think therefore even though DateBsd.m3 uses the _r functions, it should serialize.
 
 - Jay





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090920/9c81cfc2/attachment-0002.html>