luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-06 09:26:17 +01:00
Code Issues Packages Projects Releases Wiki Activity
b8aaa10a91
glib/gio/tests/contenttype.c

503 lines
15 KiB
C
Raw Normal View History

Add some contenttype tests
2010-07-05 04:27:01 +02:00
#include <gio/gio.h>
contenttype test: don't pass -1 as length g_content_type_guess() takes a gsize, not a gssize, and -1 does not mean "I am passing a NULL terminated string".
2012-05-01 21:40:15 +02:00
#include <string.h>
Add some contenttype tests
2010-07-05 04:27:01 +02:00
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
#define g_assert_content_type_equals(s1, s2) \
do { \
const char *__s1 = (s1), *__s2 = (s2); \
if (g_content_type_equals (__s1, __s2)) ; \
else \
g_assertion_message_cmpstr (G_LOG_DOMAIN, \
__FILE__, __LINE__, \
G_STRFUNC, \
#s1 " == " #s2, \
__s1, " == ", __s2); \
} while (0)
Add some contenttype tests
2010-07-05 04:27:01 +02:00
static void
test_guess (void)
{
gchar *res;
gchar *expected;
Enable contenttype test on W32, tweak it to pass (mostly) * On W32 use a real directory (SYSTEMROOT) instead of '/etc/' * Disable test_symbolic_icon() as it can't be passed (symbolic icons are not really supported) * PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves the entires (both have the same priority) https://bugzilla.gnome.org/show_bug.cgi?id=735696
2015-05-03 01:46:06 +02:00
gchar *existing_directory;
Add some contenttype tests
2010-07-05 04:27:01 +02:00
gboolean uncertain;
contenttype test: don't pass -1 as length g_content_type_guess() takes a gsize, not a gssize, and -1 does not mean "I am passing a NULL terminated string".
2012-05-01 21:40:15 +02:00
guchar data[] =
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
"[Desktop Entry]\n"
"Type=Application\n"
"Name=appinfo-test\n"
"Exec=./appinfo-test --option\n";
Add some contenttype tests
2010-07-05 04:27:01 +02:00
Enable contenttype test on W32, tweak it to pass (mostly) * On W32 use a real directory (SYSTEMROOT) instead of '/etc/' * Disable test_symbolic_icon() as it can't be passed (symbolic icons are not really supported) * PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves the entires (both have the same priority) https://bugzilla.gnome.org/show_bug.cgi?id=735696
2015-05-03 01:46:06 +02:00
#ifdef G_OS_WIN32
existing_directory = (gchar *) g_getenv ("SYSTEMROOT");
if (existing_directory)
gio/tests: fix content type guess for directory on win32 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-02-16 12:25:09 +01:00
existing_directory = g_strdup_printf ("%s" G_DIR_SEPARATOR_S, existing_directory);
Enable contenttype test on W32, tweak it to pass (mostly) * On W32 use a real directory (SYSTEMROOT) instead of '/etc/' * Disable test_symbolic_icon() as it can't be passed (symbolic icons are not really supported) * PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves the entires (both have the same priority) https://bugzilla.gnome.org/show_bug.cgi?id=735696
2015-05-03 01:46:06 +02:00
#else
existing_directory = g_strdup ("/etc/");
#endif
res = g_content_type_guess (existing_directory, NULL, 0, &uncertain);
g_free (existing_directory);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
expected = g_content_type_from_mime_type ("inode/directory");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (uncertain);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
g_free (res);
g_free (expected);
res = g_content_type_guess ("foo.txt", NULL, 0, &uncertain);
expected = g_content_type_from_mime_type ("text/plain");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_free (res);
g_free (expected);
gosxcontenttype: Fix various tests https://bugzilla.gnome.org/show_bug.cgi?id=780384
2017-03-22 06:37:43 +01:00
res = g_content_type_guess ("foo.txt", data, sizeof (data) - 1, &uncertain);
expected = g_content_type_from_mime_type ("text/plain");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_free (res);
g_free (expected);
gio/tests: fix various content type guesses on win32 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-02-16 12:27:12 +01:00
/* Sadly win32 & OSX just don't have as large and robust of a mime type database as Linux */
#ifndef G_OS_WIN32
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifndef __APPLE__
gosxcontenttype: Fix various tests https://bugzilla.gnome.org/show_bug.cgi?id=780384
2017-03-22 06:37:43 +01:00
res = g_content_type_guess ("foo", data, sizeof (data) - 1, &uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
expected = g_content_type_from_mime_type ("text/plain");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_free (res);
g_free (expected);
gosxcontenttype: Fix various tests https://bugzilla.gnome.org/show_bug.cgi?id=780384
2017-03-22 06:37:43 +01:00
res = g_content_type_guess ("foo.desktop", data, sizeof (data) - 1, &uncertain);
expected = g_content_type_from_mime_type ("application/x-desktop");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_free (res);
g_free (expected);
contenttype test: don't pass -1 as length g_content_type_guess() takes a gsize, not a gssize, and -1 does not mean "I am passing a NULL terminated string".
2012-05-01 21:40:15 +02:00
res = g_content_type_guess (NULL, data, sizeof (data) - 1, &uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
expected = g_content_type_from_mime_type ("application/x-desktop");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_free (res);
g_free (expected);
Fix /contenttype/guess test After fixing bug 674452 this test case now reliably fails, as "ABC abc" is text and definitively not PowerPoint. It previously worked as g_content_type_guess() was reading beyond the boundary of the data due to specifying -1 as data length. Update that test case to expect a PO template instead, and add two more with a definitive PO template syntax and some binary data. We do not currently have a MIME magic for PowerPoint, so we cannot actually detect it with certainty, but at least make sure that the returned MIME type is correct. https://bugzilla.gnome.org/show_bug.cgi?id=678941
2012-06-27 16:30:38 +02:00
/* this is potentially ambiguous: it does not match the PO template format,
* but looks like text so it can't be Powerpoint */
gio/tests/contenttype: Call g_content_type_guess() with valid data len g_content_type_guess() requires specifying a valid data length. Fixes a segfault when running the test. Also add an explicit check for this and return XDG_MIME_TYPE_UNKNOWN when data_size is specified as -1, to avoid crashing. https://bugzilla.gnome.org/show_bug.cgi?id=674452
2012-06-27 09:25:37 +02:00
res = g_content_type_guess ("test.pot", (guchar *)"ABC abc", 7, &uncertain);
Fix /contenttype/guess test After fixing bug 674452 this test case now reliably fails, as "ABC abc" is text and definitively not PowerPoint. It previously worked as g_content_type_guess() was reading beyond the boundary of the data due to specifying -1 as data length. Update that test case to expect a PO template instead, and add two more with a definitive PO template syntax and some binary data. We do not currently have a MIME magic for PowerPoint, so we cannot actually detect it with certainty, but at least make sure that the returned MIME type is correct. https://bugzilla.gnome.org/show_bug.cgi?id=678941
2012-06-27 16:30:38 +02:00
expected = g_content_type_from_mime_type ("text/x-gettext-translation-template");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
Fix /contenttype/guess test After fixing bug 674452 this test case now reliably fails, as "ABC abc" is text and definitively not PowerPoint. It previously worked as g_content_type_guess() was reading beyond the boundary of the data due to specifying -1 as data length. Update that test case to expect a PO template instead, and add two more with a definitive PO template syntax and some binary data. We do not currently have a MIME magic for PowerPoint, so we cannot actually detect it with certainty, but at least make sure that the returned MIME type is correct. https://bugzilla.gnome.org/show_bug.cgi?id=678941
2012-06-27 16:30:38 +02:00
g_free (res);
g_free (expected);
res = g_content_type_guess ("test.pot", (guchar *)"msgid \"", 7, &uncertain);
expected = g_content_type_from_mime_type ("text/x-gettext-translation-template");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
Fix /contenttype/guess test After fixing bug 674452 this test case now reliably fails, as "ABC abc" is text and definitively not PowerPoint. It previously worked as g_content_type_guess() was reading beyond the boundary of the data due to specifying -1 as data length. Update that test case to expect a PO template instead, and add two more with a definitive PO template syntax and some binary data. We do not currently have a MIME magic for PowerPoint, so we cannot actually detect it with certainty, but at least make sure that the returned MIME type is correct. https://bugzilla.gnome.org/show_bug.cgi?id=678941
2012-06-27 16:30:38 +02:00
g_free (res);
g_free (expected);
res = g_content_type_guess ("test.pot", (guchar *)"\xCF\xD0\xE0\x11", 4, &uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
expected = g_content_type_from_mime_type ("application/vnd.ms-powerpoint");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
Fix /contenttype/guess test After fixing bug 674452 this test case now reliably fails, as "ABC abc" is text and definitively not PowerPoint. It previously worked as g_content_type_guess() was reading beyond the boundary of the data due to specifying -1 as data length. Update that test case to expect a PO template instead, and add two more with a definitive PO template syntax and some binary data. We do not currently have a MIME magic for PowerPoint, so we cannot actually detect it with certainty, but at least make sure that the returned MIME type is correct. https://bugzilla.gnome.org/show_bug.cgi?id=678941
2012-06-27 16:30:38 +02:00
/* we cannot reliably detect binary powerpoint files as long as there is no
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
* defined MIME magic, so do not check uncertain here
*/
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_free (res);
g_free (expected);
gio/tests/contenttype: Call g_content_type_guess() with valid data len g_content_type_guess() requires specifying a valid data length. Fixes a segfault when running the test. Also add an explicit check for this and return XDG_MIME_TYPE_UNKNOWN when data_size is specified as -1, to avoid crashing. https://bugzilla.gnome.org/show_bug.cgi?id=674452
2012-06-27 09:25:37 +02:00
res = g_content_type_guess ("test.otf", (guchar *)"OTTO", 4, &uncertain);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
expected = g_content_type_from_mime_type ("application/x-font-otf");
contenttype tests: better assertions I recently had to track down why these tests failed. Turned out that some rogue package on my system had installed mime types that declared all files with 3 letter names to be 'chemical/x-turbomole-vibrational'. This change will make it more obvious what is going on by mentioning the mime types in the assertion message.
2013-12-21 17:56:24 +01:00
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
g_free (res);
g_free (expected);
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#endif /* __APPLE__ */
Add tests for x-content type sniffing This test exercises the tree matching parts of gcontenttype.c
2013-12-23 18:11:03 +01:00
res = g_content_type_guess (NULL, (guchar *)"%!PS-Adobe-2.0 EPSF-1.2", 23, &uncertain);
expected = g_content_type_from_mime_type ("image/x-eps");
g_assert_content_type_equals (expected, res);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (uncertain);
Add tests for x-content type sniffing This test exercises the tree matching parts of gcontenttype.c
2013-12-23 18:11:03 +01:00
g_free (res);
g_free (expected);
tests: Add a test for g_content_type_guess() with no arguments It should produce a generic result, but not crash. It was previously crashing on macOS. Signed-off-by: Philip Withnall <withnall@endlessm.com> Fixes: #1729
2019-03-19 12:18:48 +01:00
/* The data below would be detected as a valid content type, but shouldn’t be read at all. */
res = g_content_type_guess (NULL, (guchar *)"%!PS-Adobe-2.0 EPSF-1.2", 0, &uncertain);
expected = g_content_type_from_mime_type ("application/x-zerosize");
g_assert_content_type_equals (expected, res);
g_assert_false (uncertain);
g_free (res);
g_free (expected);
gio/tests: fix various content type guesses on win32 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-02-16 12:27:12 +01:00
#endif /* G_OS_WIN32 */
Add some contenttype tests
2010-07-05 04:27:01 +02:00
}
static void
test_unknown (void)
{
gchar *unknown;
gchar *str;
unknown = g_content_type_from_mime_type ("application/octet-stream");
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_content_type_is_unknown (unknown));
Add some contenttype tests
2010-07-05 04:27:01 +02:00
str = g_content_type_get_mime_type (unknown);
g_assert_cmpstr (str, ==, "application/octet-stream");
g_free (str);
g_free (unknown);
}
static void
test_subtype (void)
{
gchar *plain;
gchar *xml;
plain = g_content_type_from_mime_type ("text/plain");
xml = g_content_type_from_mime_type ("application/xml");
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_content_type_is_a (xml, plain));
g_assert_true (g_content_type_is_mime_type (xml, "text/plain"));
Add some contenttype tests
2010-07-05 04:27:01 +02:00
g_free (plain);
g_free (xml);
}
static gint
find_mime (gconstpointer a, gconstpointer b)
{
if (g_content_type_equals (a, b))
return 0;
return 1;
}
static void
test_list (void)
{
GList *types;
gchar *plain;
gchar *xml;
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifdef __APPLE__
gosxcontenttype: Fix various tests https://bugzilla.gnome.org/show_bug.cgi?id=780384
2017-03-22 06:37:43 +01:00
g_test_skip ("The OSX backend does not implement g_content_types_get_registered()");
return;
#endif
Add some contenttype tests
2010-07-05 04:27:01 +02:00
plain = g_content_type_from_mime_type ("text/plain");
xml = g_content_type_from_mime_type ("application/xml");
types = g_content_types_get_registered ();
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_cmpuint (g_list_length (types), >, 1);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
/* just check that some types are in the list */
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_nonnull (g_list_find_custom (types, plain, find_mime));
g_assert_nonnull (g_list_find_custom (types, xml, find_mime));
Add some contenttype tests
2010-07-05 04:27:01 +02:00
gio/tests: Use g_list_free_full() convenience function
2012-01-02 15:20:42 +01:00
g_list_free_full (types, g_free);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
g_free (plain);
g_free (xml);
}
static void
test_executable (void)
{
gchar *type;
tests: use Windows mime type for executable According to https://stackoverflow.com/a/43916291/1277510 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-01-21 22:32:52 +01:00
#ifdef G_OS_WIN32
type = g_content_type_from_mime_type ("application/vnd.microsoft.portable-executable");
/* FIXME: the MIME is not in the default `MIME\Database\Content Type` registry.
* g_assert_true (g_content_type_can_be_executable (type));
*/
g_free (type);
#else
Add some contenttype tests
2010-07-05 04:27:01 +02:00
type = g_content_type_from_mime_type ("application/x-executable");
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_content_type_can_be_executable (type));
Add some contenttype tests
2010-07-05 04:27:01 +02:00
g_free (type);
type = g_content_type_from_mime_type ("text/plain");
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_content_type_can_be_executable (type));
Add some contenttype tests
2010-07-05 04:27:01 +02:00
g_free (type);
tests: use Windows mime type for executable According to https://stackoverflow.com/a/43916291/1277510 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-01-21 22:32:52 +01:00
#endif
Misc test additions
2010-07-05 09:09:36 +02:00
type = g_content_type_from_mime_type ("image/png");
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_false (g_content_type_can_be_executable (type));
Misc test additions
2010-07-05 09:09:36 +02:00
g_free (type);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
}
Add some more tests
2010-07-05 05:42:07 +02:00
static void
test_description (void)
{
gchar *type;
gchar *desc;
type = g_content_type_from_mime_type ("text/plain");
desc = g_content_type_get_description (type);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_nonnull (desc);
Add some more tests
2010-07-05 05:42:07 +02:00
g_free (desc);
g_free (type);
}
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
static void
test_icon (void)
{
gchar *type;
GIcon *icon;
type = g_content_type_from_mime_type ("text/plain");
icon = g_content_type_get_icon (type);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (G_IS_ICON (icon));
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
if (G_IS_THEMED_ICON (icon))
{
const gchar *const *names;
names = g_themed_icon_get_names (G_THEMED_ICON (icon));
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifdef __APPLE__
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "text-*"));
tests/contenttype: icon name text/plain doesn't have text-x-generic on win32 The g_content_type_get_icon() function for win32 can lookup the DefaultIcon associated with .txt and return a different result. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-10-14 15:09:55 +02:00
#elif defined(G_OS_WIN32)
g_assert_cmpuint (g_strv_length ((GStrv) names), >, 0);
gio: Show icons based on file's mime type on OS X The patch basically just grabs the implementation of g_content_type_get_icon_internal() from gcontenttype.c - the only difference is that it first converts UTI to MIME using g_content_type_get_mime_type() and at the end frees this temporary MIME type. https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-27 23:45:14 +02:00
#else
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "text-plain"));
g_assert_true (g_strv_contains (names, "text-x-generic"));
gio: Show icons based on file's mime type on OS X The patch basically just grabs the implementation of g_content_type_get_icon_internal() from gcontenttype.c - the only difference is that it first converts UTI to MIME using g_content_type_get_mime_type() and at the end frees this temporary MIME type. https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-27 23:45:14 +02:00
#endif
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
}
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_object_unref (icon);
g_free (type);
type = g_content_type_from_mime_type ("application/rtf");
icon = g_content_type_get_icon (type);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (G_IS_ICON (icon));
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
if (G_IS_THEMED_ICON (icon))
{
const gchar *const *names;
names = g_themed_icon_get_names (G_THEMED_ICON (icon));
gio/tests: fix test_icon on win32 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-02-16 12:39:39 +01:00
#ifdef G_OS_WIN32
g_assert_true (g_strv_contains (names, "text-x-generic"));
#else
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "application-rtf"));
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifndef __APPLE__
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "x-office-document"));
gio/tests: fix test_icon on win32 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-02-16 12:39:39 +01:00
#endif
gio: Show icons based on file's mime type on OS X The patch basically just grabs the implementation of g_content_type_get_icon_internal() from gcontenttype.c - the only difference is that it first converts UTI to MIME using g_content_type_get_mime_type() and at the end frees this temporary MIME type. https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-27 23:45:14 +02:00
#endif
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
}
g_object_unref (icon);
g_free (type);
}
static void
test_symbolic_icon (void)
{
tests: Re-enable contenttype tests under AddressSanitizer This is a partial revert of commit f3783520514a6ba8d15454e14175d086883cdb0f, as the previous commits have silenced the AddressSanitizer warnings for `GContentType`. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: #2310
2021-09-27 14:11:21 +02:00
#ifndef G_OS_WIN32
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
gchar *type;
GIcon *icon;
type = g_content_type_from_mime_type ("text/plain");
icon = g_content_type_get_symbolic_icon (type);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (G_IS_ICON (icon));
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
if (G_IS_THEMED_ICON (icon))
{
const gchar *const *names;
names = g_themed_icon_get_names (G_THEMED_ICON (icon));
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifdef __APPLE__
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "text-*-symbolic"));
g_assert_true (g_strv_contains (names, "text-*"));
gio: Show icons based on file's mime type on OS X The patch basically just grabs the implementation of g_content_type_get_icon_internal() from gcontenttype.c - the only difference is that it first converts UTI to MIME using g_content_type_get_mime_type() and at the end frees this temporary MIME type. https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-27 23:45:14 +02:00
#else
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "text-plain-symbolic"));
g_assert_true (g_strv_contains (names, "text-x-generic-symbolic"));
g_assert_true (g_strv_contains (names, "text-plain"));
g_assert_true (g_strv_contains (names, "text-x-generic"));
gio: Show icons based on file's mime type on OS X The patch basically just grabs the implementation of g_content_type_get_icon_internal() from gcontenttype.c - the only difference is that it first converts UTI to MIME using g_content_type_get_mime_type() and at the end frees this temporary MIME type. https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-27 23:45:14 +02:00
#endif
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
}
g_object_unref (icon);
g_free (type);
type = g_content_type_from_mime_type ("application/rtf");
icon = g_content_type_get_symbolic_icon (type);
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (G_IS_ICON (icon));
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
if (G_IS_THEMED_ICON (icon))
{
const gchar *const *names;
names = g_themed_icon_get_names (G_THEMED_ICON (icon));
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "application-rtf-symbolic"));
g_assert_true (g_strv_contains (names, "application-rtf"));
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifndef __APPLE__
tests: Use g_assert_*() instead of g_assert() in contenttype tests g_assert_*() give more helpful error messages on failure, and aren’t compiled out by G_DISABLE_ASSERT. Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-03-19 12:18:07 +01:00
g_assert_true (g_strv_contains (names, "x-office-document-symbolic"));
g_assert_true (g_strv_contains (names, "x-office-document"));
gio: Show icons based on file's mime type on OS X The patch basically just grabs the implementation of g_content_type_get_icon_internal() from gcontenttype.c - the only difference is that it first converts UTI to MIME using g_content_type_get_mime_type() and at the end frees this temporary MIME type. https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-27 23:45:14 +02:00
#endif
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
}
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_object_unref (icon);
g_free (type);
Enable contenttype test on W32, tweak it to pass (mostly) * On W32 use a real directory (SYSTEMROOT) instead of '/etc/' * Disable test_symbolic_icon() as it can't be passed (symbolic icons are not really supported) * PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves the entires (both have the same priority) https://bugzilla.gnome.org/show_bug.cgi?id=735696
2015-05-03 01:46:06 +02:00
#endif
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
}
Add tests for x-content type sniffing This test exercises the tree matching parts of gcontenttype.c
2013-12-23 18:11:03 +01:00
static void
test_tree (void)
{
const gchar *tests[] = {
"x-content/image-dcf",
"x-content/unix-software",
"x-content/win32-software"
};
const gchar *path;
GFile *file;
gchar **types;
Fix signedness warning in gio/tests/contenttype.c gio/tests/contenttype.c: In function ‘test_tree’: gio/tests/contenttype.c:337:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ 337 | for (i = 0; i < G_N_ELEMENTS (tests); i++) | ^
2020-11-17 23:43:09 +01:00
gsize i;
Add tests for x-content type sniffing This test exercises the tree matching parts of gcontenttype.c
2013-12-23 18:11:03 +01:00
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#if defined(__APPLE__) || defined(G_OS_WIN32)
tests: skip test_tree on win32 Currently it simply crashes, because types == NULL. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2022-01-21 22:48:13 +01:00
g_test_skip ("The OSX & Windows backends do not implement g_content_type_guess_for_tree()");
gosxcontenttype: Fix various tests https://bugzilla.gnome.org/show_bug.cgi?id=780384
2017-03-22 06:37:43 +01:00
return;
#endif
Add tests for x-content type sniffing This test exercises the tree matching parts of gcontenttype.c
2013-12-23 18:11:03 +01:00
for (i = 0; i < G_N_ELEMENTS (tests); i++)
{
path = g_test_get_filename (G_TEST_DIST, tests[i], NULL);
file = g_file_new_for_path (path);
types = g_content_type_guess_for_tree (file);
g_assert_content_type_equals (types[0], tests[i]);
g_strfreev (types);
g_object_unref (file);
}
}
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
gcontenttype: Make filename valid utf-8 string before processing The `g_content_type_guess_for_tree` function segfaults currently when processing filenames that are not valid unicode strings. Let's use the `g_filename_to_utf8` and `g_utf8_make_valid` functions before other processing to prevent that. Let's also add a test for it to avoid this in future. Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3168
2023-11-13 13:14:01 +01:00
static void
test_tree_invalid_encoding (void)
{
gchar *path;
gchar *name;
GFile *tmpdir;
GFile *file;
gchar **types;
GError *error = NULL;
g_test_bug ("https://gitlab.gnome.org/GNOME/glib/-/issues/3168");
#if defined(__APPLE__) || defined(G_OS_WIN32)
g_test_skip ("The OSX & Windows backends do not implement g_content_type_guess_for_tree()");
return;
#endif
path = g_dir_make_tmp ("gio-test-tree-invalid-encoding-XXXXXX", &error);
g_assert_no_error (error);
tmpdir = g_file_new_for_path (path);
g_free (path);
name = g_strdup_printf ("\260");
file = g_file_get_child (tmpdir, name);
g_free (name);
g_file_replace_contents (file, "", 0, NULL, FALSE, 0, NULL, NULL, &error);
if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_INVALID_ARGUMENT))
{
g_test_skip ("Unable to create testing file with non-ASCII characters.");
g_object_unref (tmpdir);
g_object_unref (file);
g_clear_error (&error);
return;
}
g_assert_no_error (error);
types = g_content_type_guess_for_tree (tmpdir);
g_strfreev (types);
g_file_delete (file, NULL, &error);
g_assert_no_error (error);
g_object_unref (file);
g_file_delete (tmpdir, NULL, &error);
g_assert_no_error (error);
g_object_unref (tmpdir);
}
xdgmime: fix special case for mime_type_subclass Currently, all mime types are considered subclasses of application/octet-stream, but according to the freedesktop standard, everything but the inode/* types is a subclass of application/octet-stream. Update the special case for application/octet-stream so that all types but inode/* will match with it and add unit test for it. https://bugzilla.gnome.org/show_bug.cgi?id=782311
2017-05-10 18:09:35 +02:00
static void
test_type_is_a_special_case (void)
{
gboolean res;
tests: Drop use of g_test_bug_base() Include the base URI in the `g_test_bug()` calls instead. This resolves inconsistencies between the old bug base (bugzilla.gnome.org) and the new bug base (gitlab.gnome.org). It also has the advantage that the URI passed to `g_test_bug()` is now clickable in the code editor, rather than being split across two locations. See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/275#note_303175 Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-05-13 23:12:29 +02:00
g_test_bug ("https://bugzilla.gnome.org/show_bug.cgi?id=782311");
xdgmime: fix special case for mime_type_subclass Currently, all mime types are considered subclasses of application/octet-stream, but according to the freedesktop standard, everything but the inode/* types is a subclass of application/octet-stream. Update the special case for application/octet-stream so that all types but inode/* will match with it and add unit test for it. https://bugzilla.gnome.org/show_bug.cgi?id=782311
2017-05-10 18:09:35 +02:00
/* Everything but the inode type is application/octet-stream */
res = g_content_type_is_a ("inode/directory", "application/octet-stream");
g_assert_false (res);
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#if !defined(__APPLE__) && !defined(G_OS_WIN32)
xdgmime: fix special case for mime_type_subclass Currently, all mime types are considered subclasses of application/octet-stream, but according to the freedesktop standard, everything but the inode/* types is a subclass of application/octet-stream. Update the special case for application/octet-stream so that all types but inode/* will match with it and add unit test for it. https://bugzilla.gnome.org/show_bug.cgi?id=782311
2017-05-10 18:09:35 +02:00
res = g_content_type_is_a ("anything", "application/octet-stream");
g_assert_true (res);
gio: Show icons based on file's mime type on OS X The patch basically just grabs the implementation of g_content_type_get_icon_internal() from gcontenttype.c - the only difference is that it first converts UTI to MIME using g_content_type_get_mime_type() and at the end frees this temporary MIME type. https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-27 23:45:14 +02:00
#endif
xdgmime: fix special case for mime_type_subclass Currently, all mime types are considered subclasses of application/octet-stream, but according to the freedesktop standard, everything but the inode/* types is a subclass of application/octet-stream. Update the special case for application/octet-stream so that all types but inode/* will match with it and add unit test for it. https://bugzilla.gnome.org/show_bug.cgi?id=782311
2017-05-10 18:09:35 +02:00
}
OSX: Use xdgmime system to guess content type from data Closes: Bug #788401 The problem is described here: https://bugzilla.gnome.org/show_bug.cgi?id=788401 This patch introduces the use of the xdgmime system to guess the content type from data. So you can guess for example the type public.svg-image from the file content of a svg file. This patch only applies to MacOS. A test for the regression is also included.
2017-10-11 15:59:16 +02:00
static void
test_guess_svg_from_data (void)
{
const gchar svgfilecontent[] = "<svg xmlns=\"http://www.w3.org/2000/svg\"\
xmlns:xlink=\"http://www.w3.org/1999/xlink\">\n\
<rect x=\"10\" y=\"10\" height=\"100\" width=\"100\"\n\
style=\"stroke:#ff0000; fill: #0000ff\"/>\n\
</svg>\n";
gboolean uncertain = TRUE;
gchar *res = g_content_type_guess (NULL, (guchar *)svgfilecontent,
sizeof (svgfilecontent) - 1, &uncertain);
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifdef __APPLE__
OSX: Use xdgmime system to guess content type from data Closes: Bug #788401 The problem is described here: https://bugzilla.gnome.org/show_bug.cgi?id=788401 This patch introduces the use of the xdgmime system to guess the content type from data. So you can guess for example the type public.svg-image from the file content of a svg file. This patch only applies to MacOS. A test for the regression is also included.
2017-10-11 15:59:16 +02:00
g_assert_cmpstr (res, ==, "public.svg-image");
#elif defined(G_OS_WIN32)
g_test_skip ("svg type detection from content is not implemented on WIN32");
#else
g_assert_cmpstr (res, ==, "image/svg+xml");
#endif
g_assert_false (uncertain);
g_free (res);
}
MacOS: create_cstr_from_cfstring uses safe conversion - use CFStringGetCString During testing with gdk-pixbuf I noticed failures during content type to mime conversion. The root reason was the unsafe conversion used in create_cstr_from_cfstring. The problem was addressed in commit c60226e0a1cae40a96 but that was reverted. I noticed the commit only when I had fixed the problem. In addition I added a test to check the content type to mime conversion on MacOS. This problem is discussed in Bug #788936. See: https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-15 13:16:44 +02:00
static void
test_mime_from_content (void)
{
Revert "gio, glib: Use G_OS_DARWIN for code that is for such environments" This reverts commit 476e33c3f3632bd32370fadc67b10d61da9a4098. We’ve decided to remove `G_OS_DARWIN` in favour of recommending people use `__APPLE__` instead. As per the discussion on #2802 and linked issues, * Adding a new define shifts the complexity from “which of these platform-provided defines do I use” to “which platform-provided defines does G_OS_DARWIN use” * There should ideally be no cases where a user of GLib has to use their own platform-specific code, since GLib should be providing appropriate abstractions * Providing a single `G_OS_DARWIN` to cover all Apple products (macOS and iOS) hides the complexity of what the user is actually testing: are they testing for the Mach kernel, the Carbon and/or Cocoa user space toolkits, macOS vs iOS vs tvOS, etc Helps: #2802
2022-11-02 11:01:09 +01:00
#ifdef __APPLE__
MacOS: create_cstr_from_cfstring uses safe conversion - use CFStringGetCString During testing with gdk-pixbuf I noticed failures during content type to mime conversion. The root reason was the unsafe conversion used in create_cstr_from_cfstring. The problem was addressed in commit c60226e0a1cae40a96 but that was reverted. I noticed the commit only when I had fixed the problem. In addition I added a test to check the content type to mime conversion on MacOS. This problem is discussed in Bug #788936. See: https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-15 13:16:44 +02:00
gchar *mime_type;
mime_type = g_content_type_get_mime_type ("com.microsoft.bmp");
g_assert_cmpstr (mime_type, ==, "image/bmp");
g_free (mime_type);
mime_type = g_content_type_get_mime_type ("com.compuserve.gif");
g_assert_cmpstr (mime_type, ==, "image/gif");
g_free (mime_type);
mime_type = g_content_type_get_mime_type ("public.png");
g_assert_cmpstr (mime_type, ==, "image/png");
g_free (mime_type);
mime_type = g_content_type_get_mime_type ("public.text");
g_assert_cmpstr (mime_type, ==, "text/*");
g_free (mime_type);
mime_type = g_content_type_get_mime_type ("public.svg-image");
g_assert_cmpstr (mime_type, ==, "image/svg+xml");
g_free (mime_type);
#elif defined(G_OS_WIN32)
g_test_skip ("mime from content type test not implemented on WIN32");
#else
g_test_skip ("mime from content type test not implemented on UNIX");
#endif
}
Add some contenttype tests
2010-07-05 04:27:01 +02:00
int
main (int argc, char *argv[])
{
g_test_init (&argc, &argv, NULL);
g_test_add_func ("/contenttype/guess", test_guess);
OSX: Use xdgmime system to guess content type from data Closes: Bug #788401 The problem is described here: https://bugzilla.gnome.org/show_bug.cgi?id=788401 This patch introduces the use of the xdgmime system to guess the content type from data. So you can guess for example the type public.svg-image from the file content of a svg file. This patch only applies to MacOS. A test for the regression is also included.
2017-10-11 15:59:16 +02:00
g_test_add_func ("/contenttype/guess_svg_from_data", test_guess_svg_from_data);
MacOS: create_cstr_from_cfstring uses safe conversion - use CFStringGetCString During testing with gdk-pixbuf I noticed failures during content type to mime conversion. The root reason was the unsafe conversion used in create_cstr_from_cfstring. The problem was addressed in commit c60226e0a1cae40a96 but that was reverted. I noticed the commit only when I had fixed the problem. In addition I added a test to check the content type to mime conversion on MacOS. This problem is discussed in Bug #788936. See: https://bugzilla.gnome.org/show_bug.cgi?id=788936
2017-10-15 13:16:44 +02:00
g_test_add_func ("/contenttype/mime_from_content", test_mime_from_content);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
g_test_add_func ("/contenttype/unknown", test_unknown);
g_test_add_func ("/contenttype/subtype", test_subtype);
g_test_add_func ("/contenttype/list", test_list);
g_test_add_func ("/contenttype/executable", test_executable);
Add some more tests
2010-07-05 05:42:07 +02:00
g_test_add_func ("/contenttype/description", test_description);
contenttype: Improve test coverage Excercise more parts of the guessing machinery. These tests rely on the mime database being present.
2012-04-08 16:17:32 +02:00
g_test_add_func ("/contenttype/icon", test_icon);
Test content type icons more thoroughly Check we actually get the right icon names, and check that symbolic icons fall back to non-symbolic ones.
2014-02-23 18:03:13 +01:00
g_test_add_func ("/contenttype/symbolic-icon", test_symbolic_icon);
Add tests for x-content type sniffing This test exercises the tree matching parts of gcontenttype.c
2013-12-23 18:11:03 +01:00
g_test_add_func ("/contenttype/tree", test_tree);
gcontenttype: Make filename valid utf-8 string before processing The `g_content_type_guess_for_tree` function segfaults currently when processing filenames that are not valid unicode strings. Let's use the `g_filename_to_utf8` and `g_utf8_make_valid` functions before other processing to prevent that. Let's also add a test for it to avoid this in future. Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3168
2023-11-13 13:14:01 +01:00
g_test_add_func ("/contenttype/tree_invalid_encoding",
test_tree_invalid_encoding);
xdgmime: fix special case for mime_type_subclass Currently, all mime types are considered subclasses of application/octet-stream, but according to the freedesktop standard, everything but the inode/* types is a subclass of application/octet-stream. Update the special case for application/octet-stream so that all types but inode/* will match with it and add unit test for it. https://bugzilla.gnome.org/show_bug.cgi?id=782311
2017-05-10 18:09:35 +02:00
g_test_add_func ("/contenttype/test_type_is_a_special_case",
test_type_is_a_special_case);
Add some contenttype tests
2010-07-05 04:27:01 +02:00
return g_test_run ();
}
Reference in New Issue Copy Permalink