This is a weird report that is not really a Scintilla bug, but that makes use of Scintilla's GTK platform on Windows hard as the default GTK2 bundle for Windows, as can be found on gtk.org (www.gtk.org), is partially incompatible with GCC > 3, and Scintilla suffers of that slight incompatibility since [e4f4d934f9c0cfe0da5c9dce8455d967ff692c62].
The issue is easily visible, as the autoc popup is blank. Actually, one can see those warnings on stderr:
GLib-GObject WARNING : specified instance size for type `SmallScroller' is smaller than the parent type's `GtkScrolledWindow' instance size GLib CRITICAL : g_once_init_leave: assertion `initialization_value != 0' failed GLib-GObject CRITICAL : g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Gtk CRITICAL : gtk_container_set_border_width: assertion `GTK_IS_CONTAINER (container)' failed Gtk CRITICAL : gtk_scrolled_window_set_policy: assertion `GTK_IS_SCROLLED_WINDOW (scrolled_window)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed Gtk CRITICAL : gtk_container_add: assertion `GTK_IS_CONTAINER (container)' failed
Here are the details (also found on the patch's subject):
GtkScrolledWindow contains a bitfield, and GCC 3.4 and 4.8 don't agree on the size of the structure (regardless of -mms-bitfields):
As Windows GTK2 bundle is built with GCC 3, it requires types derived from GtkScrolledWindow to be at least 88 bytes, which means we need to add some fake padding to fill in the extra 4 bytes.
There is however no other issue with the layout difference as we never access any GtkScrolledWindow fields ourselves.
See http://lists.geany.org/pipermail/devel/2015-April/thread.html#9379
I could understand you wouldn't want this little hack to workaround what apparently is a compiler ABI break, but I believe it's simple enough to be worth it, especially as it causes problem with current versions of GCC and the most commonly used GTK2 bundle for Windows.
Note that this issue doesn't affect the GTK3 bundle from gtk.org, which seem to have been built with a newer GCC.
Diving into the GCC bug tracker https://gcc.gnu.org/bugzilla/ hasn't shown a good candidate for this. There's a lot of interpretation involved with bitfields. The newer compiler's interpretation (allowing guint bit fields to allocate just 16-bits) does appear closer to the SysV 386 ABI http://www.sco.com/developers/devspecs/abi386-4.pdf which is what GCC is following. The ABI supplement https://01.org/sites/default/files/file_attach/intel386-psabi-1.0.pdf doesn't modify this area.
Committed as [e9f9c9].
Related
Commit: [e9f9c9]