Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
This is a source-compatible change and only breaks ABI with respect to
truly ancient binaries (and those binaries are already broken for other
reasons).
Back in the day, functions like g_get_user_name() used to return strings
in the system codepage instead of utf8 (as they do today).
It was decided at some point to change these functions to return utf8,
breaking source compatibility but keeping ABI compatibility. This was
done by exporting new symbols with names like g_get_user_name_utf8() and
using a #define of the old name over to the new name (so that newly
compiled code would link against the _utf8 version, but old binaries
would continue to use the non-utf8 variant).
Meanwhile, glib has undergone several ABI breaks on Windows since, so
those old binaries don't work anymore.
Start to clean up this mess by removing the #define renaming. New
binaries calling g_get_user_name() will now link against
g_get_user_name() and it will return utf8.
We must keep the functions like g_get_user_name_utf8() for binary
compatibility with recently built programs (ie: ones built with the
renaming). Nobody should have ever been calling these directly and of
course they can return utf8, so just add them as internal wrappers in the
.c file and declare them _GLIB_EXTERN there.
One day, if we feel like breaking Windows ABI again, we can finish the
cleanup by dropping the wrappers. There is some talk of introducing
something like 'ABI compatible for two years' and this change would be
compatible with such a regime.
https://bugzilla.gnome.org/show_bug.cgi?id=693204
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
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).
https://bugzilla.gnome.org/show_bug.cgi?id=691608
The previous fix didn't work, because every place within glib that
used any of the functions also needed to be including win32compat.h.
So, move the prototypes back to their original headers (but at least
all in one place at the bottom).
https://bugzilla.gnome.org/show_bug.cgi?id=688109
To avoid -Wmissing-prototype warnings, we need to prototype both the
original and the _utf8 versions of all of the functions that have had
_utf8-renaming on Windows. But duplicating all the prototypes is ugly,
so rather than doing them "in-place", move them all to a new header
file just for that.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
I didn't do this comprehensively, since there's a lot of it, mainly
due to the GDBus object manager stuff, but anyone trying to use
that would fail fast due to lack of the gdbus code generator.
My main goal was to get API additions to existing classes like
g_data_input_stream_read_line_utf8(), as well as the lower level new
API like glib-unix.h.
https://bugzilla.gnome.org/show_bug.cgi?id=676816
gutils.[hc] is a bit of a grab bag, so lets start cleaning
things up by moving all the environment-related functions
into separate genviron.[hc] files.
The private _g_getenv_nomalloc has been moved to its sole caller.
When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.
So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.
http://bugzilla.gnome.org/show_bug.cgi?id=659326
If gtk-doc sees 'Returns ...' written in the text of the documentation
for a macro, it thinks that you are talking about the return value.
Avoid doing that and use 'Returns:' explicitly if we mean to.
Use the opt-out mechanism introduced in gtk-doc 1.16 to work
around problems with the _utf8 renaming games that the win32
port is playing in our headers.
https://bugzilla.gnome.org/show_bug.cgi?id=638449
2009-02-23 Tor Lillqvist <tml@novell.com>
Bug 570501 - g_win32_get_system_data_dirs uses invalid conversion
of function pointer to object pointer
* glib/gutils.c (g_win32_get_system_data_dirs_for_module): Change
the type of the function's parameter to be explicitly a function
pointer.
* glib/gutils.h (_g_win32_get_system_data_dirs): Modify
declaration and the only caller, the inline
_g_win32_get_system_data_dirs(), accordingly. Add comments
pointing out these are internal GLib functions.
svn path=/trunk/; revision=7899
2008-11-28 Behdad Esfahbod <behdad@gnome.org>
Bug 562638 – GDebugKey key member should be const
* glib/gutils.h: Change GDebugKey key member from gchar * to
const gchar *.
svn path=/trunk/; revision=7709
2008-09-13 Tor Lillqvist <tml@novell.com>
* glib/gutils.h
* glib/gwin32.h: Deprecate G_WIN32_DLLMAIN_FOR_DLL_NAME(),
g_win32_get_package_installation_directory() and
g_win32_get_package_installation_subdirectory() as their
documentation has warned for a while. Sorry that I forgot to do
this before 2.18.0.
* glib/gwin32.c (g_win32_get_package_installation_directory):
Print a warning if a non-NULL package parameter is passed to this
function, as that is deprecated usage, as the documentation says.
svn path=/trunk/; revision=7480
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
* glib/gutils.h: Use "__attribute__ ((__gnu_inline__))" for inlining
if either __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__ are defined. In
gcc version prior to 4.3 no correct C99-inline was implemented which
has semantic differences to GNU inline.
svn path=/trunk/; revision=6733
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
2008-03-03 Matthias Clasen <mclasen@redhat.com>
* glib/gutils.h: Add a version of G_INLINE_FUNC for
__GNUC__ && __GNUC_STDC_INLINE__, patch by Jakub Jelinek
svn path=/trunk/; revision=6616
2008-02-24 Tor Lillqvist <tml@novell.com>
* glib/gutils.h: Mention G_WIN32_DLLMAIN_FOR_DLL_NAME() will be
deprecated in the future.
* glib/gutils.c: Drop use of G_WIN32_DLLMAIN_FOR_DLL_NAME(). Use a
minimal DllMain() instead that just saves the DLL handle.
(g_win32_get_system_data_dirs_for_module, _glib_get_locale_dir)
(get_module_share_dir): Use
g_win32_get_package_installation_directory_of_module().
svn path=/trunk/; revision=6570