From: John B. <joh...@ho...> - 2007-10-09 17:09:46
|
Michael Gerdau <mgerdau@...> writes: > > > > Options: > > > 1) Port it to use already available mingw API > > > > Could be a lot of work. > > Really ?!? ... > I'd expect it to be little more than editing a headerfile (sort of). > You're right, of course, and I have already made the change. It's jut that there are probably more functions like that. I doubt that they switched to VC++ 2005 just to call localtime_s. > > > 2) Add API to mingw > > > > I could probably do this, but this would probably involve peeking in the > > Platform SDK header files, which is Very Naughty... > > Refering to MSDN is considered good practice around here. > This will work if MSDN has complete information. If they do not show the values of the defined constants accepted or returned by the function, than I cannot add it. It is not the usual practice to show the values. After all, you are not doing arithmetic with them. This particular function does not use any such constants; I am just speaking generally. > > I don't really have any intention of doing any of 1 - 5 (as I said, it could > > be a lot of work), but: > > I don't know what you consider "a lot of work" I can't define it, but I know it when I do it. >but I bet you already > invested way more than would be required to port it. True, so it's more than just the work. Part of it is that although I compile open source libraries and programs all the time, I am not knowledgeable on the internal workings of any of them. I prefer to confine my efforts to preprocessor directives. Replacing a function (which requires understanding the code) is "a lot of work" for me. Typing 'make' creates work for the compiler, not me. > > a) Are you saying that MinGW can, in fact, use Platform SDK headers and > > libraries,...? > > Yes. Search the archives as this had been discussed in the past. > OK. |