The start_position arguments are passed to pcre_exec() as the
startoffset, which is in bytes (not characters).
I had recently a doubt about this, so it's better to document it.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
To update this code you need to fetch the last version of the code
from: https://github.com/win-iconv/win-iconv
Then you need to ensure 3 things:
- the line ends are in unix format
- some of the methods do not expose a const on the prototype
refer to the commit b8c13a01b6bd5601eb3519dd3b20daed4bbc2e72
on how to fix it
- fix one uninitialized variable if not yet fixed upstream
refer to 7e0cb48dee9a8ecd87d403b7941ad3209eee658c
https://bugzilla.gnome.org/show_bug.cgi?id=761126
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
Commit 855594c changed the expected error for the regex
/(?P<sub>foo)\g<sub/ for PCRE 8.38, but actually PCRE changed the error
raised by this invalid regex in 8.37, so we should check for the new error
from 8.37 and upwards.
Please see comments #21 and #22 of bug 740573 regarding this commit.
To be honest, i don't remember what problems were caused by it returning the
number of bytes it *wanted* to write instead of the number of bytes
it actually wrote. Probably related to the fact that fwrite could
independently fail, and ignoring its return value ignores that error.
https://bugzilla.gnome.org/show_bug.cgi?id=748064
PCRE 8.38 changed the parsing of this invalid regex. It still fails,
but with a different error (since PCRE r1539,
<http://vcs.pcre.org/pcre?view=revision&revision=1539>).
The regex /(?P<sub>foo)\g<sub/ used to raise MISSING_BACK_REFERENCE but
now raises MISSING_SUBPATTERN_NAME_TERMINATOR, so we can still have a
test for the latter.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=759808
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c7fb1343eff27b5f1d0bcbef4e333b9.
Its documentation mentions that it logs a 'critical warning', but since
the macro implementation calls g_warn_message(), it does not log a
critical message, but a regular warning.
Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Also get rid of the items regarding G_HAVE_*INLINE as they aren't used
anymore as they are removed from configure.ac.
Thanks to John Emmas and desrt for the earlier patch for getting
rid of the C4005 warnings.
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.
According to the C spec, any undefined identifier used in a #if
expression is taken to have a numerical value of zero.
Commit db2367e8782d7a39fc3e93d13f6a16f10cad04c2 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
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
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
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
ntdef.h is a header that is normally only shipped with MinGW, not Visual
Studio, which broke the build in commit 975cb91. Fix this by including
winternl.h, which typedef's the NTSTATUS type in question on both Visual
Studio and MinGW/mingw-w64, as well as pre-2008 Visual Studio.
Clean up this inclusion part a little bit as well.
