summaryrefslogtreecommitdiff
path: root/gdk-pixbuf
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'fix-gir-annotations' into 'master'Emmanuele Bassi2023-05-022-39/+39
|\ | | | | | | | | Fix some GIR annotations See merge request GNOME/gdk-pixbuf!146
| * Fix some GIR annotationsGuillaume Gomez2022-10-142-39/+39
| |
* | meson: Override dependencies to improve usage as a subprojectNirbheek Chauhan2022-12-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, gdk-pixbuf can be consumed as a subproject without making any changes to the build files of a project. All you need to do is provide a wrap file with a `[provide]` section: https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section This is also necessary because otherwise projects need to hard-code the subproject name, which might be `gdk-pixbuf` when using `wrap-git` or `gdk-pixbuf-2.42.10` when using `wrap-file` (to build from a release tarball). This can cause conflicts between different subprojects that consume gdk-pixbuf differently. Other projects like glib, cairo, pango, etc already do this.
* | jpeg: Bump up the memory limit to 1GBEmmanuele Bassi2022-10-231-1/+2
|/ | | | | | Let's play some more whack-a-mole. Fixes: #218
* jpeg: Increase memory limit for loading image dataJake Dane2022-08-191-1/+1
| | | | | | | | | As fix for security issue #205 when loading image data the memory size was limited to 100 MB. That seemed like a good threshold. For larger images, from around 18 megapixels (MP) and up though not for all such images, this threshold was too low. Increasing the threshold too 300 MB seems to work better and lets larger images load. Fixes #216.
* Merge branch 'disable_relocation_on_static' into 'master'Emmanuele Bassi2022-08-092-4/+3
|\ | | | | | | | | Disable relocation when built as a static libary on Windows See merge request GNOME/gdk-pixbuf!136
| * Disable relocation when built as a static libary on WindowsHesham Essam2022-06-032-4/+3
| |
* | jpeg: Limit the memory size when loading image dataEmmanuele Bassi2022-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Specially crafted JPEG images may lead to a crash when their size is too large; in the most benign of cases, the OS might terminate the process after it tries to allocate all the memory in the world. We can tell libjpeg to limit the size of the memory pool when loading, to avoid this kind of result. For the time being, 100 MB seems like a good threshold. Original patch by: Sam Ezeh <sam.z.ezeh@gmail.com> Fixes: #205
* | Fix the check for maximum value of LZW initial code size.Robert Ancell2022-02-021-2/+2
| | | | | | | | | | | | | | | | This value is the number of bits for each symbol (i.e. colour index) decoded via LZW. The maximum LZW code is specified as 12 bits, so the value here can only be 11 as two additional code words are required (clear and end of information) that immediately uses an additional bit. This implementation has always been wrong, and the Firefox implementation has the same issue so it seems a common misinterpretation of the spec. This has been changed here to avoid an assertion later in the LZW decoder. Note that there is never any reason for a GIF to be encoded with more than 8 bits of colour information, as the colour tables only support up to 8 bits.
* | Add an assertion that checks for maximum LZW code sizeRobert Ancell2022-02-021-0/+2
|/
* gdk_pixbuf_new() - Clear the pixbuf's memory buffer to avoid returning ↵Federico Mena Quintero2022-01-251-1/+1
| | | | | | uninitialized memory Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/199
* docs: Remove invalid nullable annotationEmmanuele Bassi2021-11-091-1/+1
| | | | The return value of GdkPixbufModuleBeginLoadFunc is NULL only on error.
* docs: Fix the XPM data annotationEmmanuele Bassi2021-11-091-4/+4
| | | | Make sure that the array is annotated as zero-terminated.
* Merge branch 'ebassi/loader-vfunc' into 'master'Emmanuele Bassi2021-11-091-39/+171
|\ | | | | | | | | Turn GdkPixbufModule functions into typed callbacks See merge request GNOME/gdk-pixbuf!123
| * Turn GdkPixbufModule functions into typed callbacksEmmanuele Bassi2021-11-091-39/+171
| | | | | | | | This way we can properly document and annotate them.
* | Merge branch 'ebassi/tiff-types' into 'master'Emmanuele Bassi2021-11-091-6/+7
|\ \ | | | | | | | | | | | | tiff: Use non-deprecated C99 integer types See merge request GNOME/gdk-pixbuf!124
| * | tiff: Use non-deprecated C99 integer typesEmmanuele Bassi2021-11-091-6/+7
| |/ | | | | | | | | The old `uint16` and `uint32` types have been deprecated in favour of the C99 integer types `uint16_t` and `uint32_t`.
* | Merge branch 'ebassi/issue-143' into 'master'Emmanuele Bassi2021-11-091-34/+43
|\ \ | | | | | | | | | | | | | | | | | | jpeg: Do not rely on UB around setjmp/longjmp Closes #143 See merge request GNOME/gdk-pixbuf!116
| * | jpeg: Do not rely on UB around setjmp/longjmpebassi/issue-143Emmanuele Bassi2021-04-221-34/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are reading and writing a structure before and after a sigsetjmp/longjmp pair without declaring it volatile. This is undefined behaviour, and even if most compilers and toolchains won't have any issue with that, it's better to avoid it if at all possible. The simplest fix is to declare the variable in a separate function, and then pass it by reference. Fixes: #143
* | | gif: Check for overflow when compositing or clearing frames.Robert Ancell2021-06-031-8/+13
| |/ |/| | | | | | | | | Fixes: #190 Similar to fix in 086e8adf4cc352cd11572f96066b001b545f354e
* | docs: Fix the image-data linkEmmanuele Bassi2021-05-191-2/+2
| | | | | | | | Reference the anchor in the class description.
* | build: Fix shared GDI+ loaders iterationebassi/issues-185Emmanuele Bassi2021-04-211-2/+2
|/ | | | | | The native loaders for Windows are not stored in a dictionary. Fixes: #185
* bmp: Use g_set_error_literal()Emmanuele Bassi2021-04-161-4/+4
| | | | Never use g_set_error() without a format string.
* Use g_filename_display_name() with files inside GError messagesEmmanuele Bassi2021-04-161-4/+12
| | | | | The path of a file may contain non-Unicode glyphs, as file names have their own encoding.
* Revert "build: Use a dict for pkg-config file variables"Emmanuele Bassi2021-04-091-12/+10
| | | | | | | This reverts commit f265a94336c17716b2dcb33198ec34ebf926f98e. This change requires Meson ≥ 0.56, and Fedora 33 still has 0.55.3. We're going to un-revert the change once we can depend on a newer version.
* build: Use a dict for loader dataEmmanuele Bassi2021-04-081-34/+69
| | | | Makes it slightly easier to visually parse and modify.
* build: Use a dict for pkg-config file variablesEmmanuele Bassi2021-04-071-10/+12
| | | | Avoids a ton of string manipulations, and leaves escaping to Meson.
* docs: Update pixbuf-loader styleebassi/gi-docgenEmmanuele Bassi2021-03-211-79/+89
|
* docs: Update pixbuf-animation styleEmmanuele Bassi2021-03-211-70/+83
|
* docs: Update pixbuf-scale styleEmmanuele Bassi2021-03-211-28/+27
|
* docs: Update pixbuf-util styleEmmanuele Bassi2021-03-211-31/+45
|
* docs: Update pixbuf-data styleEmmanuele Bassi2021-03-211-22/+38
|
* docs: Update pixdata styleEmmanuele Bassi2021-03-211-54/+63
|
* docs: Update gdk-pixbuf-io styleEmmanuele Bassi2021-03-211-272/+313
|
* docs: Clean up GdkPixbuf's core APIEmmanuele Bassi2021-03-211-70/+106
| | | | Use proper summaries; remove gtk-doc'isms; document properties.
* docs: Generate the GdkPixdata API referenceEmmanuele Bassi2021-03-212-29/+31
| | | | Different introspection file, different API reference.
* docs: Port to the gi-docgen syntax and styleEmmanuele Bassi2021-03-2112-399/+315
| | | | | Drop the gtk-doc SECTION markers, and move documentation to classes or separate documents.
* Fix inclusion guards for gdk-pixbuf-features.hEmmanuele Bassi2021-03-211-4/+4
| | | | | | | | | | | Use the idiomatic form: #ifndef __FOO_H__ #define __FOO_H__ ... #endif /* __FOO_H__ */
* docs: Fix the deprecation annotation for AlphaModeEmmanuele Bassi2021-03-211-1/+1
| | | | The syntax is "Deprecated: version: message".
* gdk-pixbuf/gdk-pixbuf-io.c: fix build without gmoduleFabrice Fontaine2021-02-091-0/+2
| | | | | | | | | | | | | | | Fix the following build failure: ../gdk-pixbuf/gdk-pixbuf-io.c: In function 'gdk_pixbuf_io_init': ../gdk-pixbuf/gdk-pixbuf-io.c:681:16: error: implicit declaration of function 'gdk_pixbuf_get_module_file'; did you mean '_gdk_pixbuf_get_module'? [-Werror=implicit-function-declaration] 681 | module_file = gdk_pixbuf_get_module_file (); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | _gdk_pixbuf_get_module Fixes: - http://autobuild.buildroot.org/results/6cd54c497f5d19342ec94ece713547b887e4c02d Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
* Meson: Override programsXavier Claessens2021-01-291-0/+1
| | | | | Meson's gnome module could want to find programs such as gdk-pixbuf-pixdata when invoking glib-compile-resources.
* gif: Honor "revert to previous" behaviour on the first frame.Robert Ancell2021-01-051-8/+0
| | | | | | | | | | | | The code originally failed to load GIFs that had this set (4607c8e9) and then changed to silently ignoring it (af71489c). Reverting to the background on the first frame seems completely reasonable and is the behaviour of Firefox/Chrome. The [current GIF spec](https://www.w3.org/Graphics/GIF/spec-gif89a.txt) doesn't indicate any issue doing this and it matches what Firefox/Chrome does. Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/166
* animation: silence gtk doc warningsPaolo Borelli2021-01-021-7/+6
|
* Include pixbuf loader API in the gir filePaolo Borelli2021-01-021-0/+1
|
* gif: Do all of gif_init() with a single readSimon McVittie2020-12-121-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | As documented in the introductory comment, the interface of the various functions in the GIF loader is that they read all the bytes they need, or return -1 if not enough are available. Since commit 5212d69f "gif: Replace old buffer management code with GByteArray", the incremental loader strictly depends on that assumption. Unfortunately, gif_init() didn't conform to that interface. If there were enough bytes available for the GIF signature (GIF87a or GIF89a) but not enough bytes for the screen descriptor, it would return -1 having already consumed the first 6 bytes of the stream. A subsequent retry with more data available would start from the beginning of the screen descriptor, and immediately raise an error because the screen descriptor is extremely unlikely to start with another copy of the "GIF8" magic number. The regression test tests/pixbuf-short-gif-write.c would have detected this, but was accidentally disabled by commit 7f0b214a "tests: Conditionally build and run tests". This seems most easily fixed by reading the whole of the 13-byte fixed-length header in one go. Adjust the offsets into the buffer used to parse the screen descriptor accordingly. Signed-off-by: Simon McVittie <smcv@debian.org>
* Make enum GType registration thread safeEmmanuele Bassi2020-12-071-4/+6
| | | | | Use g_once_init_enter/leave to ensure that enumeration types can be registered across threads.
* gif: Fix LZW decoder accepting invalid LZW code.Robert Ancell2020-12-081-6/+7
| | | | | | | | | The code value after a reset wasn't being validated, which means we would accept invalid codes. This could cause an infinite loop in the decoder. Fixes CVE-2020-29385 Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/164
* gif: Fix GIF images without a Graphic Control Extension rendering colour 0 ↵Robert Ancell2020-11-231-0/+1
| | | | | | | | as the background. This was a regression introduced in 5212d69f2362f9b68ccf9385277e5c4a744b2187. Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/162
* io: Initialize variable before reading into itEmmanuele Bassi2020-11-101-5/+4
| | | | We must handle the error path, where the out argument isn't set.
* xbm: Free data in error pathEmmanuele Bassi2020-11-101-4/+5
|
View Lorry Controller Status