We were trying to squeeze 64-bit test vectors into gsize, which is fine
on 64bit systems but doesn't work very well on 32-bit.
Change that to a guint64.
This example has been causing on-and-off build breaks for quite some
time. In this case, the code for copying the generated content into the
main docs of GIO is causing problems with srcdir != destdir builds (due
to the files also being copied from the read-only srcdir during
distchecks).
We could probably work around this problem yet again, but since there is
no real benefit to having this content included, so let's remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=734469
According to the C spec, any undefined identifier used in a #if
expression is taken to have a numerical value of zero.
Commit db2367e878 introduced an #i
statement which depended on this behaviour.
gcc has a -Wundef option which warns about depending on this behaviour,
and unfortunately there are projects that are using -Werror=undef in
builds that include our headers.
Adding a check for defined(__STDC_VERSION__) before using the macro is
enough to silence gcc.
It's been a long time since we've been unconditionally saying "static
inline" in GLib headers without complaints so it's safe to assume that
all compilers that we care about support this.
One thing that is not yet totally supported is the unadorned use of the
word "inline". Depending on the flags (-std=c89, for example), even GCC
will complain about this. Detect missing C99 support and define
"inline" to "__inline" in that case. Some research shows "__inline"
appears to be the most widely-supported keyword here, but we may need to
tweak this if we get some reports of breakage.
Clean up all of the configure checks around this and define G_CAN_INLINE
unconditionally. Unfortunately, we must assume that some people are
still using G_IMPLEMENT_INLINES, we must continue to implement that
(including undefining G_CAN_INLINE and redefining G_INLINE_FUNC) if
requested.
It is not our intent to break existing users of the old-style
G_INLINE_FUNC approach and if that has happened, we may need to make
some further adjustments.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
gutils.h and gutils.c define three utility functions as inlines that are
also exported via the ABI. This is done via complicated G_INLINE_FUNC
and G_IMPLEMENT_INLINES logic.
In order to be able to remove this mess, we create a another convoluted
but slightly cleaner approach: write straight-up inline versions of the
functions named _impl() in the header. Define macros with the "public"
function names that call these inlines. From the .c file, export the
ABI versions of these functions, implemented using the _impl() version.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
Deprecate GTrashStack and remove the inline implementations for the
functions. This will help us clean up the mess that is inline functions
in GLib.
Because of how G_INLINE_FUNC worked, we have these functions on our ABI,
so we must continue to export them as normal functions. We are safe to
remove the inline versions, however, because any existing binaries will
continue to carry them and any new builds will just start using the
non-inline versions.
https://bugzilla.gnome.org/show_bug.cgi?id=757374
This partially reverts dc4361f.
As we now ensure that items using GResources and GConstructors are always
referenced so that the linker does not optimize them out in a default
Release build, we no longer need to enforce the use of /LTCG, so
/LTCG:incremental will work as well.
Whole program optimization is enabled by default in visual studio
release builds, and this causes constructors (for e.g. resources) to be
optimized away as they are not referenced from elsewhere.
This works around this by some pragma magic.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
Commit 8ece2de964 transplanted a block of
code that contained an early-exit-on-error case which freed several
variables.
Because of the move, the normal-path unconditional free of one of these
variables is now above this early exit case, so if this block is hit, it
will now be a double-free.
Remove that.
https://bugzilla.gnome.org/show_bug.cgi?id=757693
It was removed, apparently accidentally, in commit 5b48dc4.
This had the side-effect that it wasn't included in tarball releases,
which means that commit ab7b4be doesn't work when building a package.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=734469
Reviewed-by: Colin Walters <walters@verbum.org>
It's a platform-specific macro, so it belongs in glibconfig.h.
This ensures that g-ir-scanner will not pick the wrong definition
for introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=757294
Currently the doc is incomplete when builddir!=srcdir
(e.g. debian package) because glibconfig.h is generared from
configure.ac and is thus missing from srcdir. This leads to
missing doc for symbols like G_GINT64_FORMAT.
https://bugzilla.gnome.org/show_bug.cgi?id=734469
Add some simple testcases for the new bounds-checked integer arithmetic
helpers.
Include a second build of the testcase to make sure we test the fallback
code even if we are on a compiler that supports the intrinsics.
https://bugzilla.gnome.org/show_bug.cgi?id=503096
Add some helpers for builds-checked unsigned integer arithmetic to GLib.
These will be based on compiler intrinsics where they are available,
falling back to standard manual checks otherwise.
The fallback case needs to be implemented as a function (which we do
inline) because we cannot rely on statement expressions. We also
implement the intrinsics case as an inline in order to avoid people
accidentally writing non-portable code which depends on static
evaluation of the builtin.
For now there is only support for addition and multiplication for guint,
guint64 and gsize. It may make sense to add support for subtraction or
for the signed equivalents of those types in the future if we find a use
for that.
https://bugzilla.gnome.org/show_bug.cgi?id=503096
Add a dummy definition for Clang's __has_builtin() macro. This will
allow us to use __has_builtin() unconditionally, in the same way as we
already do for __has_feature().
https://bugzilla.gnome.org/show_bug.cgi?id=503096
The Windows API function RtlGetVersion() is actually a function that is
decorated by WINAPI (i.e. __stdcall), so we need to correct this so that
the symbol can be loaded correctly from ntdll.dll, so that we won't crash as
a result. Should fix the crash due to stack overflow on 32-bit builds.
https://bugzilla.gnome.org/show_bug.cgi?id=756179
