The g_autoptr() being associated with the type name works out really
well for things like GHashTable. However, it's a bit more awkward to
associate with "gchar". Also because one can't use "char".
Similarly, there are a lot of other "bare primitive array" types that
one might reasonably use.
This patch does not remove the autoptr for "gchar", even though I
think it's rather awkward and strange.
Also while we're here, add a test case for the cleanup bits.
https://bugzilla.gnome.org/show_bug.cgi?id=744747
This is necessary as we are using _GLIB_AUTOPTR_TYPENAME and
_GLIB_AUTOPTR_FUNC_NAME in gtype.h for G_DECLARE_DERIVABLE_TYPE and
G_DECLARE_FINAL_TYPE, but _GLIB_AUTOPTR_TYPENAME and
_GLIB_AUTOPTR_FUNC_NAME expand to nothing on non-GCC, causing builds on
non-GCC to break, due to bad typedef and function definitions.
This patch defines a new private macro which does what is needed on GCC
builds and does nothing on non-GCC builds, thus fixing the build.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add the missing 'none' argument to this macro in the non-GCC case. The
none parameter was added after the others and I forgot to update the
non-GCC case.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add g_auto() and g_autoptr() as helpers for declaring variables with
automatic cleanup.
Add some macros to help types define cleanup functions for themselves.
Going forward it will be an expectation that people use this macro when
creating a new type, even if they do not intend to use the auto-cleanup
functionality for themselves.
These new macros only work on GCC and clang, which is why we resisted
adding them for so long. There exist many people who are only
interested in writing programs for these compilers, however, and a
similar API in libgsystem has proven to be extremely popular, so let's
expose this functionality to an even wider audience.
We ignore deprecation warnings when emitting the free functions, which
seems suspicious. The reason that we do this is not because we want to
call deprecated functions, but just the opposite: sometimes the free
function will be an _unref() function that is only AVAILABLE_IN newer
versions, and these warnings are also implemented as deprecation
warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
G_STRFUNC was checking __STDC_VERSION__ against the wrong value
(though it didn't actually matter, since __STDC_VERSION__ wasn't
defined in C90, so the check still only matched C99 and above anyway).
The clang code analyzer needs to know that functions like g_error
g_critical an g_return_if_fail should be seen by the analyzer in the
same way as g_assert(). That is the analyzer should think they are
fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=700268
As Visual Studio 2008 and later have support for the __pragma keyword,
where the compiler pragmas can be used in a macro, we can support
G_GNUC_BEGIN_IGNORE_DEPRECATIONS and G_GNUC_END_IGNORE_DEPRECATIONS
for Visual Studio 2008 and later, so many deprecation (C4996) warnings
can be suppressed when using these compilers when we use these macros
in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=704543
Recent versions of clang have changed __PRETTY_FUNCTION__ to always
include the function signature (rather than including the function
signature in C++ but not in C like gcc does). This causes G_STRFUNC to
give different results under clang and gcc, causing some tests with
g_test_expect_messages() to fail.
Fix this by only using __PRETTY_FUNCTION__ in C++, and using
__FUNCTION__ in C. (Under gcc this change has no effect.)
https://bugzilla.gnome.org/show_bug.cgi?id=702147
RHEL6 ships with GCC 4.4 by default, which doesn't understand the
nicer deprecated attribute that takes a message. However, we can at
least fall back to the old G_DEPRECATED, rather than silently doing
nothing.
This gives me warning messages when building OSTree on RHEL6 when I
accidentally added a usage of g_unix_fd_source_new().
https://bugzilla.gnome.org/show_bug.cgi?id=697160
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
The version number we have here is the one the function appeared
in, not the max-allowed version. Therefore 'unavailable before
VERSION' makes more sense than 'unavailable for VERSION'.
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
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
This is only supported on some compilers, so we define G_HAS_CONSTRUCTORS
when it is supported. However, when it is supported we guarantee that
both constructors and destructors work, in executables as well as shared
libraries (including runtime unloading of shared libraries).
Usage is a bit unorthodox, as some compilers need to use #pragma to
implement constructors, and #pragma can't be used in macros.
The canonical way to use this:
#ifdef G_DEFINE_CONSTRUCTOR_NEEDS_PRAGMA
#pragma G_DEFINE_CONSTRUCTOR_PRAGMA_ARGS(my_constructor)
#endif
G_DEFINE_CONSTRUCTOR(my_constructor)
static void my_constructor (void)
{
...
#ifdef G_DEFINE_DESTRUCTOR_NEEDS_PRAGMA
#pragma G_DEFINE_DESTRUCTOR_PRAGMA_ARGS(my_destructor)
#endif
G_DEFINE_DESTRUCTOR(my_destructor)
static void my_destructor (void)
{
...
Unlike G_GNUC_... macros, the new G_DEPRECATED[_FOR] are
meant as abstractions that work with different compilers.
Using a new name also lets us restrict it to 'must be placed
before the declaration', which works with more compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=661438
I've seen builds fail with
nm-connection.c:119:691: error: declaration of '_GStaticAssertCompileTimeAssertion_119' shadows a previous local [-Werror=shadow]
because several compile-time assertions ended up on the same
line. __COUNTER__ is meant specifically for the purpose of
constructing identifiers, so use it when available.
It would be good, error reporting-wise, to be able to signal which
function should be used instead of a deprecated one. GCC 4.5 added an
optional "message" payload to the deprecated attribute, so that:
void f1 (void) __attribute__((deprecated("Use f2 instead")));
Will expand to:
warning: f1 is deprecated: Use f2 instead
Instead of just printing:
warning: f1 is deprecated
Since we already have a G_GNUC_DEPRECATED macro we should provide a
G_GNUC_DEPRECATED_FOR macro defined as:
G_GNUC_DEPRECATED_FOR(bar)
Which would expand the deprecation message to "Use bar instead"
automatically. The deprecation message should probably be similar
to what we use in gtk-doc to match up with the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=614965
* glib/gmacros.h (G_STRUCT_OFFSETOF): Use offsetof instead of
__builtin_offsetof, for icc's sake. Proposed by Hrvoje Niksic.
svn path=/trunk/; revision=7811
2008-10-29 16:11:14 Tim Janik <timj@gtk.org>
* glib/gmacros.h: added G_PASTE() and G_STATIC_ASSERT(), based on
patches by Christian Persch and Christian Dywan. Fixes:
Bug 558381 - Add support for compile time assertions
svn path=/trunk/; revision=7633
2008-09-09 Matthias Clasen <mclasen@redhat.com>
Bug 551228 – G_STRFUNC on recent Sun compiler should be expanded to
__func__ rather than '???'
* glib/gmacros.h: Don't use glibconfig.h defines in gmacros.h,
as the comment up top says. Instead look at __STDC_VERSION__.
Problem reported by Lin Ma.
svn path=/trunk/; revision=7451
2008-05-22 10:49:37 Tim Janik <timj@imendio.com>
* glib/gmacros.h: implement G_STMT_START and G_STMT_END with
do{}while(0), which is believed to be widely portable, fixes:
Bug 519026 - G_STMT_START/G_STMT_END test a non-existent preprocessor symbol
svn path=/trunk/; revision=6922
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
2005-12-04 Matthias Clasen <mclasen@redhat.com>
* glib/gmacros.h (G_GNUC_WARN_UNUSED_RESULT): Add a macro
to make gcc warn if a function result is ignored. (#145466,
Arjan van de Ven, Alex Larsson)
* glib/gmem.h: Add the new attribute to g_realloc and
g_try_realloc.
