GNOME Bugzilla – Bug 724609
Fix build of GIO on Windows
Last modified: 2014-02-23 03:51:54 UTC
Hi, There were some recent changes (near the release of 2.39.90) to GIO which broke the build on Windows, one affects any Windows build, and the other is a MSVC-specific fix. Patches to address these issues are attached in the following comments.
Created attachment 269510 [details] [review] Fix build of handle_ip_address() on Windows Hi, This fixes the build of gio/gresolver.c as there isn't inet_aton() on Windows by using inet_addr() and checking whether it did not return successfully, otherwise reject the IPV4 address.
Created attachment 269511 [details] [review] Fix GOptionEntry array initialization on Visual C++ Hi, As Visual C++ is quite picky on the types used in a direct initialization of an array of structures, fix the build on Visual C++ by splitting up the initialization. I know this is ugly, but it's how life goes here. :( With blessings, thank you!
Comment on attachment 269510 [details] [review] Fix build of handle_ip_address() on Windows MSDN suggests that getaddrinfo() on Windows does not accept the non-standard IPv4 address formats, and so the extra check in handle_ip_address() is not needed. (You could verify that with the "resolver" test program in gio/tests/. "./resolver 209.132.180.171" should return "Name: bugzilla-web.gnome.org", but "./resolver 209.132.46251" should return an error.)
Created attachment 269664 [details] [review] Fix build of handle_ip_address() on Windows (take ii) Hi Dan, Thanks for the pointer, so this patch skips the check done by inet_aton(), as suggested, on Windows. With blessings, thank you!
Comment on attachment 269664 [details] [review] Fix build of handle_ip_address() on Windows (take ii) >Windows already rejects non-standard and non-real IPv4 numers-and-dots >addresses. typo ("numers"). Otherwise fine
Comment on attachment 269511 [details] [review] Fix GOptionEntry array initialization on Visual C++ >Visual C++ is quite zealous about checking against the types used in the >initializing of array of structures is this really a "type" thing? Or just that it doesn't allow non-constant array initializers? (Which weren't allowed in C90.) >- GOptionEntry my_entries[2] = { entries[i], { NULL } }; >+ GOptionEntry null_entry = { NULL }; >+ GOptionEntry my_entries[2]; >+ >+ my_entries[0] = entries[i]; >+ my_entries[1] = null_entry; Do you actually need null_entry, or will this work: GOptionEntry my_entries[2] = { { NULL }, { NULL } }; my_entries[0] = entries[i]; ?
Created attachment 269741 [details] [review] Simpler fix for building gio/gapplication.c Hello Dan, (In reply to comment #5) > typo ("numers"). Otherwise fine oops :). Pushed with typo fixed (In reply to comment #6) > (From update of attachment 269511 [details] [review]) > > is this really a "type" thing? Or just that it doesn't allow non-constant array > initializers? (Which weren't allowed in C90.) The errors I receive in the original code are: error C2440: 'initializing' : Cannot convert 'const GOptionEntry' to 'const gchar *' error C4047: 'initializing' : 'gchar' differs in levels of indirection from 'void *' Even by using casts, there are still the C2440 errors, which is what made me believe that this is a type thing. > Do you actually need null_entry, or will this work: > > GOptionEntry my_entries[2] = { { NULL }, { NULL } }; > > my_entries[0] = entries[i]; Hmm, it does work. So here's another patch for this. With blesings, thank you!
Review of attachment 269741 [details] [review]: Hello Dan, Thanks for the reviews. I have pushed this patch as 4825e819, and will close this bug shortly. With blessings, thank you!