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
And clarify that you must add a child watch or *not* use the
G_SPAWN_DO_NOT_REAP_CHILD flag, otherwise your child will become a
zombie on exit, and will not be reaped until the parent process exits.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
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
Even when the app author specifies G_SPAWN_LEAVE_DESCRIPTORS_OPEN,
we should avoid leaking our internal pipe machinery into the
child.
Commit message written by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=703407
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 partially reverts commit ce0022933c.
It used to be safe to use g_spawn_sync() from processes that had their
own SIGCHLD handler because it simply called wait(). When it was
changed to depend on the GLib child watching infrastructure this meant
that GLib had to own the SIGCHLD handler.
This caused hangs in at least Pidgin.
The patch contained two other improvements to the child watch code which
we want to keep, so only revert the changes to gspawn itself.
https://bugzilla.gnome.org/show_bug.cgi?id=698081
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
This is preparatory work for a future commit which will add a
"catchall" waitpid API. If we don't synchronize here with the worker
thread, race conditions are possible.
This also ensures we have an error message if someone adds a child
watch for a nonexistent pid, etc. Previously, we'd simply keep
calling waitpid() getting ECHILD, and ignoring it until the source was
removed. Now, we g_warning() and fire the source.
Thirdly, this ensures that the waitpid() call in gmain handles EINTR,
like the g_spawn_sync() one did.
https://bugzilla.gnome.org/show_bug.cgi?id=687061
Applications that use glib should not invoke waitpid with a first
argument that is nonpositive, because when such a waitpid is run in
one thread and glib waits for a subprocess in another, there is a race
condition, and the former waitpid can reap a process that was intended
for the latter. Mention this in the documentation for
g_child_watch_source_new, and in the diagnostic generated by
g_spawn_sync when its waitpid fails with errno equal to ECHILD.
Signed-off-by: Colin Walters <walters@verbum.org>
http://bugzilla.gnome.org/show_bug.cgi?id=687075
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691
Add a G_SPAWN_SEARCH_PATH_FROM_ENVP flag to GSpawnFlags so that
g_spawn_async() etc use the PATH variable from the passed-in child
environment to search for the executable.
If both this flag and the G_SPAWN_SEARCH_PATH flag are set, the
child environment is searched first and only falls back to the
PATH from the process environment if it is unset.
Bug #676398.
Rename G_SPAWN_ERROR_2BIG to G_SPAWN_ERROR_TOO_BIG (while keeping the
old name for compatibility), to fix problems with language bindings
where the old name translates into something that would be
syntactically invalid due to starting with a digit.
https://bugzilla.gnome.org/show_bug.cgi?id=671025
Document the previously uncovered case of calling g_spawn_async_with_pipes()
without a full path but no G_SPAWN_SEARCH_PATH. This runs programs from the
current directory, which might be unexpected and even dangerous in some corner
cases.
https://bugzilla.gnome.org/show_bug.cgi?id=656621
We should by default reset signal handlers; particularly with the
ability to install them via g_unix_signal_source_new(), we don't
want to call a user callback inside a fork()ed helper process.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
I was debugging gthread/tests/spawn-multithreaded.c, and while I
don't think I actually hit EINTR in any of these cases, it'd be
good to fix them anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
Fix various (out) arguments, (allow-none) and (array zero-terminated=1)
for g_spawn_*() and some others.
Some additional fixes by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=646635
2008-09-25 Tor Lillqvist <tml@novell.com>
* glib/gspawn-win32.c (do_spawn_with_pipes) (do_spawn_directly):
Just ignore the child_setup function, never call it. The is no
situation in which it could be useful on Windows. Do print a
warning, like before.
* glib/gspawn.c (g_spawn_async_with_pipes): Corresponding change
in documentation.
svn path=/trunk/; revision=7540
2008-06-11 Tor Lillqvist <tml@novell.com>
* glib/gmain.c
* glib/gspawn.c: Clarify what a "child pid" is in the doc
comments.
svn path=/trunk/; revision=6995
