Update VS property sheets

...To reflect the correct GIO headers to install

glib-mkenums: fix handling of forward enum declarations

Given

    typedef enum MyFoo MyFoo;

glib-mkenums would get confused, not notice the ";", and then keep
skipping lines until it found one that started with a "{", possibly
even going into the next file.

Fix it to just ignore those lines instead (and also, to error out if
it hits eof while parsing an enum).

https://bugzilla.gnome.org/show_bug.cgi?id=669595

docs: Add win32 gio specific api to the docs

Reported by Lethalman on IRC

Add Visual C++ 2010 projects to compile GResource tools

Added projects to compile the glib-compile-resources and gresource(-tool)
utility programs during the Visual C++ 2010 build process, "install"
the resulting binaries upon successful compilation, and dist the new
.vcxproj and .vcxproj.filters files.

Also updated the property sheet and "install" project to make sure the new
.exe's are indeed "installed" and removed from the "install" project the
dependency on the testglib project as testglib is not an exhausive test on
GLib and people might want to make that project compile different test
programs as they might need.

Just wondering: I have updated the property sheet to create the
gconstructor_as_data.h header for glib-compile-resources, but is it better
to dist that generated header instead as the VS 2008/2010 projects will
depend on a working installation of PERL on Windows?

Update Visual C++ 2008 projects

Make the "install" project depend on the glib-compile-resources gresource
projects so that these tools will be indeed installed.  Missed that in my
last commit-oops.

Also make the "install" project not to depend on the testglib project as:
-the test program in the project is not an exhausive test of the GLib
 libraries
-One may want to use the project to compile different test program(s), so
 it might be better to keep the project but not "install" the resulting
 .exe

Add Visual C++ 2008 projects for GResource tools

Add projects to build the glib-compile-resources and gresource(-tool)
utilities, and "install" these tools upon successful compilation, and dist
the new projects.

One piece of note: will it be better to dist gconstructor_as_data.h instead
of generating it in the VS build process (I generated it in the property
sheet update in this commit)?

Visual C++ 2010 projects will follow shortly.

docs: Fix typo

gtimezone: consider a leading : in TZ environment variable

When set to represent a zoneinfo file, TZ may start with :, therefore
glib needs to check it and ignore the first char when building the
resulting filename, or it won't be found.
Also, the path could be absolute, in which case it is wrong to
append /usr/share/timezone

https://bugzilla.gnome.org/show_bug.cgi?id=664237

Updated Telugu Translation

Updated Galician translations

Revert "Plug a mem leak in g_environ_unsetenv"

This reverts commit 2f4b46e3783b04cddcb2622a57b2a8e692cff68a, which was
pushed accidentally.

resources: Consolidate creation of GResource into one place

resources: tests: Plug a mem leak

==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265==    at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265==    by 0x408479B: standard_calloc (gmem.c:104)
==1265==    by 0x4084846: g_malloc0 (gmem.c:189)
==1265==    by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265==    by 0x4228A98: g_resource_load (gresource.c:253)
==1265==    by 0x804A56D: test_resource_registred (resources.c:198)

resources: tests: Plug a mem leak

==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509==    by 0x4084724: standard_malloc (gmem.c:85)
==509==    by 0x40847C7: g_malloc (gmem.c:159)
==509==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509==    by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509==    by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509==    by 0x804A48C: test_resource_data (resources.c:174)

resources: tests: Plug a mem leak

==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204==    by 0x4084724: standard_malloc (gmem.c:85)
==29204==    by 0x40847C7: g_malloc (gmem.c:159)
==29204==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204==    by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204==    by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204==    by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204==    by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204==    by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204==    by 0x417C1DB: g_object_new (gobject.c:1535)
==29204==    by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204==    by 0x4228D38: g_resource_open_stream (gresource.c:363)

resources: Init refcount to 1

This bug was exposed by fixing the following leak in the resources test:

==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204==    by 0x4084724: standard_malloc (gmem.c:85)
==29204==    by 0x40847C7: g_malloc (gmem.c:159)
==29204==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204==    by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204==    by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204==    by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204==    by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204==    by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204==    by 0x417C1DB: g_object_new (gobject.c:1535)
==29204==    by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204==    by 0x4228D38: g_resource_open_stream (gresource.c:363)

resources: Plug a mem leak

==29204== 7,192 (76 direct, 7,116 indirect) bytes in 1 blocks are definitely lost in loss record 855 of 861
==29204==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204==    by 0x4084724: standard_malloc (gmem.c:85)
==29204==    by 0x40847C7: g_malloc (gmem.c:159)
==29204==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204==    by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204==    by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204==    by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204==    by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204==    by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204==    by 0x417C1DB: g_object_new (gobject.c:1535)
==29204==    by 0x424E815: g_zlib_decompressor_new (gzlibdecompressor.c:270)
==29204==    by 0x4228DD8: g_resource_lookup_data (gresource.c:422)

resources: tests: Plug a mem leak

==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778==    by 0x4084724: standard_malloc (gmem.c:85)
==28778==    by 0x40847C7: g_malloc (gmem.c:159)
==28778==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778==    by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778==    by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778==    by 0x804C2B1: test_uri_query_info (resources.c:435)

resources: tests: Plug a mem leak

==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318==    by 0x4084724: standard_malloc (gmem.c:85)
==28318==    by 0x40847C7: g_malloc (gmem.c:159)
==28318==    by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318==    by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318==    by 0x804B39E: test_resource_registred (resources.c:283)

resources: tests: Plug a mem leak

==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820==    by 0x4084724: standard_malloc (gmem.c:85)
==27820==    by 0x40847C7: g_malloc (gmem.c:159)
==27820==    by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820==    by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820==    by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820==    by 0x804BCA7: test_resource_module (resources.c:370)

resources: Plug a mem leak

==27020== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 684 of 936
==27020==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27020==    by 0x4084724: standard_malloc (gmem.c:85)
==27020==    by 0x40847C7: g_malloc (gmem.c:159)
==27020==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==27020==    by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==27020==    by 0x40B5277: g_variant_get_variant (gvariant.c:749)
==27020==    by 0x4273182: gvdb_table_value_from_item (gvdb-reader.c:478)
==27020==    by 0x42731E8: gvdb_table_get_value (gvdb-reader.c:509)
==27020==    by 0x4228B36: do_lookup (gresource.c:280)
==27020==    by 0x4228F56: g_resource_get_info (gresource.c:492)

resources: Plug a mem leak

==26427== 24 bytes in 1 blocks are definitely lost in loss record 608 of 965
==26427==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==26427==    by 0x4084724: standard_malloc (gmem.c:85)
==26427==    by 0x40847C7: g_malloc (gmem.c:159)
==26427==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==26427==    by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==26427==    by 0x40BA89F: g_variant_valist_get (gvariant.c:4482)
==26427==    by 0x40BAC23: g_variant_get_va (gvariant.c:4681)
==26427==    by 0x40BAB29: g_variant_get (gvariant.c:4633)
==26427==    by 0x4228BA5: do_lookup (gresource.c:293)
==26427==    by 0x4228F51: g_resource_get_info (gresource.c:493)

Plug a mem leak in g_environ_unsetenv

==9458== 10 bytes in 1 blocks are definitely lost in loss record 16 of 39
==9458==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==9458==    by 0x4221A1F: vasprintf (vasprintf.c:78)
==9458==    by 0x40C6065: g_vasprintf (gprintf.c:314)
==9458==    by 0x409D894: g_strdup_vprintf (gstrfuncs.c:509)
==9458==    by 0x409D8C9: g_strdup_printf (gstrfuncs.c:535)
==9458==    by 0x40672E9: g_environ_setenv (genviron.c:156)
==9458==    by 0x80490E7: test_environ_array (environment.c:78)
==9458==    by 0x40A3DB5: test_case_run (gtestutils.c:1662)
==9458==    by 0x40A40B2: g_test_run_suite_internal (gtestutils.c:1715)
==9458==    by 0x40A417C: g_test_run_suite_internal (gtestutils.c:1726)
==9458==    by 0x40A42F9: g_test_run_suite (gtestutils.c:1771)
==9458==    by 0x40A3441: g_test_run (gtestutils.c:1319)
==9458==    by 0x80493F1: main (environment.c:108)

Bug #669412.

Back to odd

2.31.16

Updates

fix memory leak in g_bookmark_file_parse()

https://bugzilla.gnome.org/show_bug.cgi?id=669334

Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>

Updated Norwegian bokmål translation

gio/tests/file: use g_file_new_tmp()

Rather than misusing g_file_open_tmp(), misuse g_file_new_tmp()
instead. Progress! (Also, gets rid of a compile warning about close()
on win32.)

gio/tests/socket-common.c: add a missing #ifdef G_OS_UNIX

gioenums.h: clean up a few GIOErrorEnum descriptions

Updated Spanish translation

Fix warning to refer to to-pixdata, not xmllint

Fix GResourceFile get_parent()

This was erronously losing the last char.

resource: tests: Use g_assert_cmp[u]int

... instead of just g_assert(), so when the test does fail, one immediately
can see the actual value the variable had.

resources: compiler: Fix entity processing of xml-stripblanks

Preserve entities instead of replacing them!

Bug #669173.

resources: compiler: Make to-pixbuf failure fatal

Bug #669123.

gsettings tool: fix a memory error

8852d4e9a08e7fbc9df7fb99a54b112f5049ee19 introduced a memory error by
taking the type of a GVariant, freeing the GVariant and using the type
after the free.

This delays the free until after we've used the type.

https://bugzilla.gnome.org/show_bug.cgi?id=669253

gio: Convert data-to-c.c to perl

Helper scripts in C can be problematic for cross compiling: the compiler
produces executables for the target platform, which the host is usually
unable to run.

https://bugzilla.gnome.org/show_bug.cgi?id=669224

docs: Clarify GSocketClient reuse policy

gio/tests: Fix out-of-source build

The glib-compile-resources --generate-dependencies call was failing,
although not stopping the build.

Failed to open file 'test2.gresource.xml': No such file or directory
Failed to open file 'test3.gresource.xml': No such file or directory
Failed to open file 'test4.gresource.xml': No such file or directory
Failed to open file 'test.gresource.xml': No such file or directory

gio.symbols: Add g_static_* symbols

... which were added in b79cfda49c.

gresource-tool: include sys/mman.h conditionally

It's only needed for code guarded by HAVE_LIBELF, so ifdef the include
as well.

Add a test to show that GMarkup properly handles > in content

resources: Add to-pixdata preprocessing option

Make constructor-based resource registration malloc free

We need to do this because constructors run before main() and
thus before any call to g_mem_set_vtable, making it impossible to
use that function if constructors call g_malloc.

We do this by making the constructors just register the static data
for lazy registration, doing the lazy registration when using
the global resource set.

resources: Minor fixes to the docs

Bump version number

2.31.14

Fix distclean

Dist gconstructor.h

Emit meaningful error messages

That is useful, even if this is only an internal tool.
I have been scratching my head why this tool would
break distcheck...

Fix builddir != src builds

Some more documentation fixes

Assorted documentation fixes

Drop menu markup functions from API docs

Fix doc syntax

Move pragmas out of function body

It seems that older gcc does not like pragmas inside functions.

Move pragmas out of function body

It seems that older gcc does not like pragmas inside functions.

Silence another deprecation warning

Silence a deprecation warning

Advantage of the new deprecation handling: there's pragmas
to shut them up locally.

Remove a check that triggers deprecation warnings

Updates

Move constructor macros to an internal header and into generated code

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.

goption: implement platform_get_argv0() for OpenBSD

https://bugzilla.gnome.org/show_bug.cgi?id=669024

gtlspassword.c: indentation fixes and doc clarifications

Updated Traditional Chinese translation(Hong Kong and Taiwan)

Updated Norwegian bokmål translation

comments/docs: Fix couple of typos

https://bugzilla.gnome.org/show_bug.cgi?id=668857

glib-compile-schemas: get strict about whitespace

It's important to have strict rules for handling of whitespace in
translated strings in GSettings schema files so that the tools
extracting the messages will end up with the same messages as the
runtime calling gettext().

The rules are designed to be simple and unambiguous yet cover most
normal uses in a convenient way.

Those rules are as follows (with rationale):

  - for <default> tags, the text content has its leading and trailing
    whitespace stripped off, but internal whitespace is not modified in
    any way.

    This allows for slightly more flexible use of whitespace without
    causing that whitespace to appear in the strings for translation.

  - for <summary> and <description> tags, the content is split into
    paragraphs.  Paragraphs are separated by two or more sequential
    newline characters.  Each paragraph has its leading and trailing
    whitespace removed and all other whitespace is normalised to a
    single ascii space character.  Finally, the paragraphs are rejoined,
    inserting exactly two newlines between them.

    This allows for longer explanations (particularly in the description
    tag) using a natural format that, when normalised, will display
    nicely in toolkits.

This patch implements the rules for <default> tags.  The schema compiler
currently ignores <summary> and <description> tags.

README: Fix potentially extremely annoying typo

Updated Spanish translation

Updated Spanish translation

GSettings: two memory use fixes

First, correct a rather dubious case of accessing a GSettingsSchemaKey
after clearing it.  This was technically okay because only the key name
was accessed (and it is not owned by the struct) but it looks very
wrong.

Second, have g_settings_backend_write() sink the passed in GVariant*.
Not all backends get this right, and I'm starting to like the pattern of
virtual function wrappers being responsible for sinking the parameters
that they are documented as consuming.

gdbus-codegen: Use C array instead of GValueArray

GValueArray was deprecated in bug 667228 and since we never change the
size of the array, it was kinda dumb to just GValueArray in the first
place.

https://bugzilla.gnome.org/show_bug.cgi?id=667228

Signed-off-by: David Zeuthen <davidz@redhat.com>

GKeyFile: allow loading from empty strings

GKeyFile supports empty files and also supports loading from the string
"", but will fail with a critical if you try:

  - explicit length == 0
  - data == NULL

length == 0 should always be valid, and data == NULL should be valid in
the case that length == 0, so add some testcases for those and fix the
code up to allow them.

https://bugzilla.gnome.org/show_bug.cgi?id=668756

GDBusInterface: add dup_object() method

This is needed for thread-safety ... yes, it would have been better to
make get_object() return a full reference and have something like a
peek_object() method return a borrowed reference for C convenience
(only a single vfunc would have been needed). But such an ABI break is
too late now...

Signed-off-by: David Zeuthen <davidz@redhat.com>

gio.symbols: Remove removed g_menu_markup_* symbols

Signed-off-by: David Zeuthen <davidz@redhat.com>

gmain: fix a bunch of comment typos in g_get_monotonic_time()

And remove a comment about Windows in the fallback implementation that
no longer applies, since there's now a separate Windows-specific
implementation.

docs: Fix formatting in glib-compile-resource man page

Fixup the formatting in the example rule for --generate-dependencies.

Updated POTFILES.in

keyfile tests: Fix windows build using portable g_setenv

docs: Fix the glib-compile-resources docs

Add a tag missing from commit 45783c5927f32cae965c67db14adb8422373d345.

Drop the GMenu markup functions

The parser has been moved into Gtk in a modified form and the printer
was never really useful anyway (except for debugging/testing).

e G_SOURCE_CONTINUE/REMOVE internally

Now that we have these macros, we should use them.
This commit covers everything in gio/.

Use G_SOURCE_CONTINUE/REMOVE internally

Now that we have these macros, we should use them.
This commit covers everything in glib/.

GHash: add note about randomness in hashing

To clarify our statements about being robust against outside attackers
degrading the performance of your hashtable.

resources: tool: Fix a compiler warning

Use G_GSIZE_FORMAT.

resources: compiler: Add autoselected output format

This allows simplifying the make rules.

Bug #668539.

resources: compiler: Add dependency generator

Bug #668532.

resources: compiler: Allow stripping blanks from xml data

It's hardly useful to bloat the resource data with blanks intended only
for human readability, so add a preprocessing option that uses xmllint --noblanks
to strip these.

Bug #667929.

GKeyFile: make list separators effective again

We must preserve the list_separator across clear;init
sequences.

Fix the new test

Add a test for g_key_file_set_list_separator

A recent 'harmless' fix broke it...

GArray: initialize the clear_func pointer

https://bugzilla.gnome.org/show_bug.cgi?id=668650

gresource-tool: fix the build

Macro to insert a new GNode "after" the given sibling.

https://bugzilla.gnome.org/show_bug.cgi?id=626258

Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>

Honor the glib_cv_g_atomic_lock_free env var in configure

This fixes bug: https://bugzilla.gnome.org/show_bug.cgi?id=668572

Deprecate GValueArray

The GValueArray type was added in a time, during the Jurassic era or so,
when GArray did not have a representable GType. The GValueArray API has
various issues as well:

  - it doesn't match the other GLib array types;
  - it is not reference counted;
  - the structure is fully exposed on the stack, so it cannot be
    extended to add reference counting;
  - it cannot be forcibly resized.

The nice thing is that now we have a GArray type that can replace in
full GValueArray, so we can deprecate the latter, and reduce the
complexity in GLib, application code, and bindings.

https://bugzilla.gnome.org/show_bug.cgi?id=667228

array: Add a clear function

Like GPtrArray has a "free function" that can be used to free memory
associated to each pointer in the array, GArray would benefit from
having a "clear function" that can be used to clear the content of
each element of the array when it's removed, or when the entire array
is freed.

https://bugzilla.gnome.org/show_bug.cgi?id=667243