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
Don't refer to g_mkdtemp() when documenting g_mkdtemp_full() and
speaking about the function itself, and remove mention of flags in
aforementioned g_mkdtemp_full(), as it doesn't have such an argument
(but g_mkstemp_full() does).
https://bugzilla.gnome.org/show_bug.cgi?id=777493
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Adds the filename annotation for all file names
and things which can contain file names like
environment variables, argv-
On Unix they can contain anything while on Windows
they are always utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=767245
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
When calculating the array sizes in get_contents_stdio(), there is a
possibility of overflow for very large files. Rearrange the overflow
checks to avoid this.
The code already handled some possibilities of files being too large, so
no new GError has been added to handle this; the existing
G_FILE_ERROR_FAILED is re-used.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).
https://bugzilla.gnome.org/show_bug.cgi?id=710519
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
Remove workarounds for NeXTStep (last released in 1995), SunOS (1994),
HP-UX 9.x (1992) and 10.x (1995), OSF/1 / Digital UNIX / Tru64 UNIX
4.x (1999), and AIX 4.x (1999).
HP-UX 11 implements dlopen(), so dropping support for earlier versions
also lets us remove the HP-UX-specific gmodule-dld.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
We didn't actually do any real-world testing of this, and
unsurprisingly it turns out to break in at least one widely-used
configuration (Fedora 19 x86_64, ext4 on LVM).
This reverts commit 9d0c17b50102267a5029b58b1f44efbad82d8f03.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
ext3 and ext4 (for quite some time) with default mount options don't
need fsync() to ensure safety of replace-by-rename. Stop doing that for
these filesystems.
Note: this patch also impacts ext2, which is probably not safe, but I
don't know of any way to check ext2. vs the others because they all have
the same magic numbers (short of opening /proc/mount).
This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be
EXT3_SUPER_MAGIC.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Use a normal write() system call instead of fdopen() and fwrite().
This will definitely work on UNIX system and should work on Windows as
well...
As an added bonus, we can use g_close() now as well.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
g_file_set_contents() sets a GError in the event of various failures
that count occur. It uses g_filename_display_name() in order to get the
filename to include in the messages.
Factor out the error handling to make it easier to allocate the display
name only when we need it (instead of allocating it every time).
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Extents-based filesystems like knowing in advance how much data will be
written to a file in order to prevent fragmentation. If we have it, use
posix_fallocate() before writing data in g_file_set_contents().
https://bugzilla.gnome.org/show_bug.cgi?id=701560
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
open() is probably defined varargs. Casting a varargs function to an
equivalent non-varargs type and then calling it is undefined, but
gfileutils.c was doing exactly that.
Add some non-varargs wrappers to avoid the problem.
Problem reported by John Spencer.
https://bugzilla.gnome.org/show_bug.cgi?id=687600
This is a regression introduced by:
commit 6ac8e6108cf15884e28fe1ecd3042dfce0e11dfd
Author: Matthias Clasen <mclasen@redhat.com>
Date: Tue Jun 14 10:12:46 2011 -0400
Don't leak resources in error cases
