1. 14 Dec, 2018 1 commit
  2. 15 Nov, 2018 1 commit
  3. 23 Oct, 2018 4 commits
  4. 12 Sep, 2018 1 commit
    • LRN's avatar
      Enable GIO tests on Windows · ad3694b8
      LRN authored
      1) Remove the non-Windows-only condition for subdir('tests').
      2) Add libiphlpapi, libws2_32 and libsecur32 deps, needed for W32 tests.
      3) Remove the -no-undefined argument (gcc doesn't understand it,
         it *does* understand -Wl,-no-undefined; either way, the test
         compiles without this argument just fine; maybe meson adds it
         by itself - you can hardly build shared modules without it).
      4) Add or fix a number of includes
      5) Disable gdbus-objectmanager tests when building with MSVC
         (right now these tests don't work on Windows anyway, so the fact
          that MSVC can't even build them properly is irrelevant;
          most likely gdbus-codegen needs changes to put _GLIB_EXTERN
          before each function)
      ad3694b8
  5. 08 Jun, 2018 1 commit
  6. 29 May, 2017 1 commit
  7. 02 Dec, 2016 1 commit
  8. 08 May, 2015 1 commit
  9. 21 Apr, 2015 1 commit
  10. 23 Jul, 2014 1 commit
  11. 31 Jan, 2014 1 commit
  12. 21 May, 2013 1 commit
    • Dan Winship's avatar
      Use 'dumb quotes' rather than `really dumb quotes' · 4b94c083
      Dan Winship authored
      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
      4b94c083
  13. 16 Oct, 2012 1 commit
  14. 10 Apr, 2012 1 commit
  15. 15 Apr, 2011 2 commits
  16. 04 Aug, 2010 3 commits
  17. 20 Jul, 2010 1 commit
    • David Zeuthen's avatar
      GDBus: Add support for D-Bus type 'h' (ie. G_VARIANT_TYPE_HANDLE) · 2be167f5
      David Zeuthen authored
      This allows sending and receiving D-Bus messages with instances of the
      'h' D-Bus type. Unlike libdbus-1's dbus_message_iter_get_basic()
      method, g_variant_get_handle() does not return a duplicated unix file
      descriptor (that must be closed with close(2)) - instead, it returns
      an index that can be used to get/dup the file descriptor from a
      GUnixFDList object that can be obtained from the GDBusMessage object.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      2be167f5
  18. 15 Jul, 2010 1 commit
  19. 17 Jun, 2010 1 commit
    • David Zeuthen's avatar
      GDBusMessage: Fix bug when deserializing a message · 79d32c2f
      David Zeuthen authored
      See https://bugzilla.gnome.org/show_bug.cgi?id=621838 for the whole
      story. The problem was that we ended up reading data from arrays of
      arrays when we were just supposed to be aligning the buffers.
      
      Also add a host of debug infrastructure that was needed to find the
      root cause. For now it can be turned on only via defining
      DEBUG_SERIALIZER. In the future we might want to make it work via
      G_DBUS_DEBUG. In a nutshell, the added debug info looks like this
      
      Parsing blob (blob_len = 0x0084 bytes)
        0000: 6c 01 00 01  3c 00 00 00  41 00 00 00  37 00 00 00    l...<...A...7...
        0010: 08 01 67 00  08 61 61 79  61 7b 73 76  7d 00 00 00    ..g..aaya{sv}...
        0020: 01 01 6f 00  08 00 00 00  2f 66 6f 6f  2f 62 61 72    ..o...../foo/bar
        0030: 00 00 00 00  00 00 00 00  03 01 73 00  06 00 00 00    ..........s.....
        0040: 4d 65 6d 62  65 72 00 00  00 00 00 00  34 00 00 00    Member......4...
        0050: 03 00 00 00  63 77 64 00  01 73 00 00  23 00 00 00    ....cwd..s..#...
        0060: 2f 68 6f 6d  65 2f 64 61  76 69 64 7a  2f 48 61 63    /home/davidz/Hac
        0070: 6b 69 6e 67  2f 67 6c 69  62 2f 67 69  6f 2f 74 65    king/glib/gio/te
        0080: 73 74 73 00                                           sts.
      
      Parsing headers (blob_len = 0x0084 bytes)
        Reading type a{yv} from offset 0x000c: array spans 0x0037 bytes
          Reading type {yv} from offset 0x0010
            Reading type y from offset 0x0010: 0x08 '
            Reading type v from offset 0x0011
              Reading type g from offset 0x0014: 'aaya{sv}'
          Reading type {yv} from offset 0x001e
            Reading type y from offset 0x0020: 0x01 ''
            Reading type v from offset 0x0021
              Reading type o from offset 0x0024: '/foo/bar'
          Reading type {yv} from offset 0x0031
            Reading type y from offset 0x0038: 0x03 ''
            Reading type v from offset 0x0039
              Reading type s from offset 0x003c: 'Member'
      Parsing body (blob_len = 0x0084 bytes)
        Reading type (aaya{sv}) from offset 0x0047
          Reading type aay from offset 0x0048: array spans 0x0000 bytes
          Reading type a{sv} from offset 0x004c: array spans 0x0034 bytes
            Reading type {sv} from offset 0x0050
              Reading type s from offset 0x0050: 'cwd'
              Reading type v from offset 0x0058
                Reading type s from offset 0x005b: '/home/davidz/Hacking/glib/gio/tests'
      OK
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      79d32c2f
  20. 14 May, 2010 1 commit
    • David Zeuthen's avatar
      GDBus: Fix serialization of empty arrays · bb6530eb
      David Zeuthen authored
      It turns out that we didn't observe padding (neither when reading nor
      writing) for empty arrays which (apparently) is needed according to
      the D-Bus spec and reference implementation. A simple test case to
      provoke this behavior is as follows (notice the lack of 4 bytes worth
      of padding at position 0x0064):
      
       Error calling dbus_message_demarshal() on this blob: org.freedesktop.DBus.Error.InvalidArgs: Message is corrupted (Alignment padding not null)
       0000: 6c 01 00 01  2e 00 00 00  41 00 00 00  37 00 00 00    l.......A...7...
       0010: 08 01 67 00  08 73 61 7b  73 76 7d 61  73 00 00 00    ..g..sa{sv}as...
       0020: 01 01 6f 00  08 00 00 00  2f 66 6f 6f  2f 62 61 72    ..o...../foo/bar
       0030: 00 00 00 00  00 00 00 00  03 01 73 00  06 00 00 00    ..........s.....
       0040: 4d 65 6d 62  65 72 00 00  11 00 00 00  30 31 32 33    Member......0123
       0050: 34 35 36 37  38 39 30 31  32 33 34 35  36 00 00 00    4567890123456...
       0060: 00 00 00 00  0e 00 00 00  09 00 00 00  53 6f 6d 65    ............Some
       0070: 74 68 69 6e  67 00                                    thing.
      
       The blob was generated from the following GVariant value:
       ('01234567890123456', @a{sv} {}, ['Something'])
      
       If the blob was encoded using DBusMessageIter, the payload would have been:
      
       0000: 6c 01 00 01  32 00 00 00  41 00 00 00  36 00 00 00    l...2...A...6...
       0010: 01 01 6f 00  08 00 00 00  2f 66 6f 6f  2f 62 61 72    ..o...../foo/bar
       0020: 00 00 00 00  00 00 00 00  03 01 73 00  06 00 00 00    ..........s.....
       0030: 4d 65 6d 62  65 72 00 00  08 01 67 00  08 73 61 7b    Member....g..sa{
       0040: 73 76 7d 61  73 00 00 00  11 00 00 00  30 31 32 33    sv}as.......0123
       0050: 34 35 36 37  38 39 30 31  32 33 34 35  36 00 00 00    4567890123456...
       0060: 00 00 00 00  00 00 00 00  0e 00 00 00  09 00 00 00    ................
       0070: 53 6f 6d 65  74 68 69 6e  67 00                       Something.
       ** ERROR:gdbus-serialization.c:547:check_serialization: code should not be reached
       Aborted
      
      and this is now in the libdbus-1-using serialization test case.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      bb6530eb
  21. 13 May, 2010 1 commit
  22. 10 May, 2010 1 commit
  23. 06 May, 2010 2 commits