On Mon, Aug 3, 2015 at 6:42 AM, Corinna Vinschen wrote: > Hang on. So you suggest that Glibc, Cygwin, as well as any other > implementation based on the localtime.c code from Arthur David Olson, > stop using the additional struct members? Despite them doing the right > thing where the POSIX implementation is lacking? Because there's one > lib you need which doesn't work as expected, rather than rebuilding it > with a matching fix? That doesn't sound overly convincing to me.
It's not just one library that I use that has tripped over this. My brief research into workarounds led me to the glibc guys shrugging off another project's report. I bet there has been plenty of time spent on this on the application side that has not left a trail for me to find. > > Other than that, you didn't answer the question: How is a library > supposed to know that the non-NULL pointer value is just garbage? I think that is the wrong question. The problem is when there is nothing telling anyone anything until something crashes. There is nothing in the official documentation of the API to inform a user that they must prepare the struct any particular way. There are two ways the library would not find itself crashing from structs it didn't like: Not use undocumented members that are pointers that can be garbage, **OR** tell everyone how to initialize the structs, through the POSIX spec or through man pages. > > I'm firmly with the GLibc guys here... > As far as I can tell the Glibc guys did not solve anyone's problem. I'm interested in a solution at the libmozjs level and I'm interested in getting struct tm in line with its documentation one way or the other. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple