This reverts commit 1422e5f812. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
This reverts commit da7a31a052. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
The user data parameters in callbacks need to be named user_data to
generate correct closure attributes in the introspection data. This
updates parameters missed in GNOME/glib!2633.
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files glib/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
Rather than using the fixed-type compiler builtins
(`__builtin_uadd_overflow()`, etc.), use the generic versions
(`__builtin_add_overflow()`). This avoids issues with matching the
definition of GLib types (such as `guint` and particularly `gsize`) to
basic C types (`int`, `long`, `long long`), as the mapping can vary
between platforms.
See https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
Adjust the fallback inline functions similarly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2523
This is technically an API break, but since the type is meant to be
opaque (third party code is not meant to treat it like an integer) it
should not cause problems.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
The __declspec(dllexport) attribute in itself doesn't imply
'extern' - thus any intended variable declaration with
GLIB_VAR/GOBJECT_VAR would actually be a variable definition. With
C compilers defaulting to -fcommon, this isn't an issue, but
upcoming compilers (GCC 10 and Clang 11) will default to -fno-common,
ending up with duplicate definitions of these variables.
GTimeVal is subject to the year 2038 problem, since its `tv_sec` field
is a `glong`, which is 32 bits on 32-bit platforms.
Use `guint64` to represent microsecond-precision time since the Unix
epoch; or use `GDateTime` for full date/time representation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1438
They were changed in 6a2cfde2 to reuse the G_MAXINT values but
parsing nexted macros is currently broken in g-i and results in wrong
values.
Add value annotations for g-i to override the values.
This also moves the annotations to the macro definitions to have
everything g-i uses in one place.
We have a common pattern for reference counting in GLib, but we always
implement it with ad hoc code. This is a good chance at trying to
standardise the implementation and make it public, so that other code
using GLib can take advantage of shared behaviour and semantics.
Instead of simply taking an integer variable, we should create type
aliases, to immediately distinguish the reference counting semantics of
the code; we can handle mixing atomic reference counting with a
non-atomic type (and vice versa) by using differently signed values for
the atomic and non-atomic cases.
The gatomicrefcount type is modelled on the Linux kernel refcount_t
type; the grefcount type is added to let single-threaded code bases to
avoid paying the price of atomic memory barriers on reference counting
operations.
This pollutes the reserved compiler namespace and breaks applications
trying to do their own feature detection. For instance, this falsely
detects that alloca is not a builtin on gcc:
#include <glib.h>
#if defined(__has_builtin)
# if !__has_builtin(alloca)
# error "wtf glib?"
# endif
#else
/* version-checking to determine alloca existence */
#endif
Instead, define our own g_macro__has_* versions that have the
behaviour that we need.
https://bugzilla.gnome.org/show_bug.cgi?id=794635
In GUINT64_TO_BE(), for example, when compiling with -Wsign-conversion,
we get a warning due to an implicit cast from (gint64) to (guint64) when
passing the argument to __builtin_bswap64().
According to the GCC documentation, __builtin_bswap64() takes an
unsigned argument:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Cast the input appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788384
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
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
Like all macros, we need to parenthesize arguments to ensure the order
of operations is correct.
See the mail thread starting at
<http://lists.fedoraproject.org/pipermail/devel/2013-March/180302.html>
"GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64" for how this
caused trouble with GVFS (which in turn caused trouble with
LibreOffice, where running "soffice sftp://.../.../test.odt" to access
an .odt file via GVFS failed to properly type-detect that file as a
Writer document and produced bogus error messages about the file being
broken).
https://bugzilla.gnome.org/show_bug.cgi?id=695925
This macro simply evaluates the "extern" unless it has been explicitly
defined to something else.
All of the version macros (including the unversioned deprecation markers
and GLIB_AVAILABLE_IN_ALL) now include _GLIB_EXTERN as part of their
definition.
G_INLINE has also been modified to use _GLIB_EXTERN where appropriate.
This macro should never be used outside of the gmacros.h/gversonmacros.h
headers.
The effect of this patch is that "extern" has now been added to all
functions declared in installed headers. Strictly speaking, this is
something we should have had all along...
GLIB_VAR and GOBJECT_VAR have also been modified to use _GLIB_EXTERN on
non-Windows, instead of "extern" which they were using before. The
eventual goal is to use the normal version/deprecation macros on
exported variables and drop GLIB_VAR but we need to see how this will
work on Windows before we go ahead with that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
There are cases when it should be possible to define at compile time
what range of functions and types should be used, in order to get,
or restrict, the compiler warnings for deprecated or newly added
types or functions.
For instance, if GLib introduces a deprecation warning on a type in
version 2.32, application code can decide to specify the minimum and
maximum boundary of the used API to be 2.30; when compiling against
a new version of GLib, this would produce the following results:
- all deprecations introduced prior to 2.32 would emit compiler
warnings when used by the application code;
- all deprecations introduced in 2.32 would not emit compiler
warnings when used by the application code;
- all new symbols introduced in 2.32 would emit a compiler warning.
Using this scheme it should be possible to have fairly complex
situations, like the following one:
assuming that an application is compiled with:
GLIB_VERSION_MIN_REQUIRED = GLIB_VERSION_2_30
GLIB_VERSION_MAX_ALLOWED = GLIB_VERSION_2_32
and a GLib header containing:
void function_A (void) GLIB_DEPRECATED_IN_2_26;
void function_B (void) GLIB_DEPRECATED_IN_2_28;
void function_C (void) GLIB_DEPRECATED_IN_2_30;
void function_D (void) GLIB_AVAILABLE_IN_2_32;
void function_E (void) GLIB_AVAILABLE_IN_2_34;
any application code using the above functions will get the following
compiler warnings:
function_A: deprecated symbol warning
function_B: deprecated symbol warning
function_C: no warning
function_D: no warning
function_E: undefined symbol warning
This means that it should be possible to gradually port code towards
non-deprecated API gradually, on a per-release basis.
https://bugzilla.gnome.org/show_bug.cgi?id=670542
2008-05-05 Michael Natterer <mitch@imendio.com>
* glib/glib.h: #define __GLIB_H_INSIDE__ around including
everything.
* glib/*.h: check for that define instead of __G_LIB_H__ if
G_DISABLE_SINGLE_INCLUDES is defined.
* glib/gdatasetprivate.h: #include <glib.h> instead of
<glib/gdataset.h>
svn path=/trunk/; revision=6875
2008-03-14 Michael Natterer <mitch@imendio.com>
* glib/*.h: make it possible to disable single-file includes by
defining G_DISABLE_SINGLE_INCLUDES when building against GLib.
Approved by Tim Janik.
* glib/glib.h: include <glib/gslice.h>.
* glib/gi18n.h
* glib/gi18n-lib.h
* glib/gprintf.h: include <glib.h> so the above works when these
files are included without including <glib.h> first.
svn path=/trunk/; revision=6713
2007-03-15 Tor Lillqvist <tml@novell.com>
* glib/gnulib/Makefile.am (INCLUDES): Add -I$(top_srcdir)/glib so
that gregex.h finds <glib.h>.
* glib/update-pcre/Makefille.am-1: Add -DGLIB_COMPILATION so that
we don't think g_ascii_table is dllimport.
* glib/pcre/Makefile.am: Corresponding change.
* glib/update-pcre/notdll.patch: New file. Drop
dllimport/dllexport magic for the pcre symbols.
* glib/update-pcre/Makefile.am: Dist it.
* glib/update-pcre/update.sh: Apply notdll.patch.
* glib/pcre/pcre.h: Corresponding change.
2007-03-15 Tor Lillqvist <tml@novell.com>
* glib/gtypes.h: Add comment to avoid misleading people with the
large number of digits in G_PI etc. (#404338)
svn path=/trunk/; revision=5410
Wed Jun 2 00:57:16 2004 Matthias Clasen <maclas@gmx.de>
* glib/gtypes.h: Use higher precision for the mathematical
constants. (#141941, Morten Welinder)
Sun May 2 03:51:59 2004 Manish Singh <yosh@gimp.org>
* glib/gtypes.h: check for __pentium4__ when deciding whether to
use bswap for GUINT32_SWAP_LE_BE_IA32(). Fixes bug #141620.
Tue Dec 2 02:29:41 2003 Matthias Clasen <maclas@gmx.de>
Fix for #103710, Mark Jones:
* glib/gtypes.h (G_MAXINT64): Define G_{MIN,MAX,MAXU}INT{8,16,32,64}.
* configure.in: Don't put G_{MIN,MAX,MAXU}INT64 in glibconfig.h.
