Hi Joseph, > As to cdate.c, you are correct the change to how time is called is not > needed. The only change needed is the addition of the _USE_32BIT_TIME_T > define. This makes windows use a 32bit time_t definition instead of the > default 64bit time_t definition. According to MSDN, both win32 and > win64, by default, use a 64 bits definition. The use of the 64bit time_t > definition was causing a segmentation fault on windows, since bigloo > assumes the time_t value can be stored in a long. Ah I see. That's a tricky issue. Thanks for having solved it. I have now applied the _USE_32BIT_TIME_T part of the patch.
> I agree with your caution on the csocket.c changes. In fact, upon > receiving your initial response to my patches, I reviewed the changes to > csocket.c, suspecting these changes were the likely source of your > questions, and found a mistake. In get_sock_hostname, the prepocessor > condition arround the call to getsockname should reference, as it > originally did, BGL_HAVE_GETADDRINFO not BGL_HAVE_INET_ATON or > BGL_HAVE_INET_PTON. I believe I originally made the change due the > conditional definition of sin above it. In the case where neither > BGL_HAVE_INET_ATON or BGL_HAVE_INET_PTON are defined, sin is a > pointer. This would have caused the call to getsockname to fail. An > updated patch is attached. Thanks for the new patch. I will inspect this one as soon as possible. However, I'm concerned by the delay this extra inspection and testing will imposed. Would it be acceptable for you that Bigloo4.1a is released as is now, that is without the socket patch. Then, I will immediately work on the patch and prepare Bigloo4.1b for which we could take the time of going through additional testing rounds. On the other hand I would also understand that you could feel frustrated not to have the patched included as soon as 4.1a as you have provided all this nice work. Please, tell me what you think. > Additionally, as you probably noticed given the windows version defines, > I decided to use features only found in Windows XP and above. I thought > this was reasonable. In fact, we may want to consider moving the minimum > version to Vista. This would allow us to use inet_pton as well as other > functions. What are your thoughts? As XP is no longer officially supported by Microsoft (you will correct me if I'm wrong on this point), your suggestion seems perfectly fine. I don't think Bigloo must support stronger backward compatibility on Windows that Microsoft itself does :-) Cheers, -- Manuel
