Introduce "known loaders" list associating the known loader modules
with the usual file name extensions they handle.
If file name extensions match known ones we will only load the required
loader.
Add some debug infrastructure.
Disabled by default, enable with --enable-debug.
When enabled, the environment variable IMLIB2_DEBUG controls the amount
of debug output.
Also call __imlib_FlushContexts() before adding new context, not after
- It's pointless to check the new context
- Avoids (bogus) clang-analyzer warning
Summary:
Loaders from a newer version of imlib2 may be incompatible with an
older version of imlib2. Thus already running applications may
stop loading images after system upgrade, which can be extremely
unpleasant for the user.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D11678
Summary:
It can be used to load files in a process, which has no access to the file,
by passing the file descriptor to it. For example, in a sandboxed process.
Also anonymous files created with O_TMPFILE or by memfd_create() can be loaded.
Reviewers: kwo
Differential Revision: https://phab.enlightenment.org/D10262
- Make a number of functions static
- Shuffle prototypes around for nicer grouping
- Remove unused __imlib_SetImageAlphaFlag()
- Remove __imlib_FlushCache() prototype (not implemented)
__imlib_FileExtension() has (presumably by mistake) never used the
"real" file name to determine the extension so let's just drop all the
strdup'ing and return a pointer into the file string.
im->w and im->h must always be set before __imlib_AllocateData() is
called due to non-immediate loading (__imlib_AllocateData() only
comes in play when the pixel data must be loaded).
Summary:
... and add imlib_create_image_using_data_and_memory_function().
For example, it allows to load an image in one process and then
pass it through shared memory to another process without extra
memory copy.
Reviewers: kwo
Differential Revision: https://phab.enlightenment.org/D10222
Instead of assigning it (in different ways) in each loader, do it
centrally in __imlib_LoadImageWrapper().
And a couple of cleanups in code related to im->format.
Summary:
This is more secure way of using shared memory because
it's visible only to the X server and the application.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D5788
Summary:
It enhances the code, because __imlib_ShmDestroyXImage() is symmetrical
to __imlib_ShmGetXImage(), while __imlib_ShmDetach() looks unrelated.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D5787
Summary:
This check actually refers to the internal implementation
and should not be done outside this function.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D5783
Found by gcc 7:
grab.c: In function ‘__imlib_GrabXImageToRGBA’:
grab.c:85:14: error: this statement may fall through [-Werror=implicit-fallthrough=]
for (y = 0; y < h; y++)
^~~
grab.c:97:11: note: here
case 24:
^~~~
There were several potential OOM crashes in __imlib_ListFilters(),
__imlib_ListLoaders() and __imlib_TrimLoaderList().
The fix of __imlib_TrimLoaderList() is from patch by
Yuriy M. Kaminskiy <yumkam@gmail.com>.
Summary:
Imlib generates masks on the client side with the bit order
of the client. Set this bit order for produced XImages.
Reviewers: kwo
Differential Revision: https://phab.enlightenment.org/D3891
IMAGE_DIMENSIONS_OK ensures that image width and height are less then
46340, so that maximum number of pixels is ~2**31.
Unfortunately, there are a lot of code that allocates image data with
something like
malloc(w * h * sizeof(DATA32));
Obviously, on 32-bit machines this results in integer overflow,
insufficient heap allocation, with [massive] out-of-bounds heap
overwrite.
Either X_MAX should be reduced to 32767, or (w)*(h) should be checked to
not exceed ULONG_MAX/sizeof(DATA32).
Security implications:
*) for 32-bit machines: insufficient heap allocation and heap overwrite
in many image loaders, with escalation potential to remote code
execution;
*) for 64-bit machines: it seems, no impact.
Attempting to draw a 2x1 ellipse with e.g. imlib_image_draw_ellipse(x, y, 2, 1)
causes a divide-by-zero.
It seems happy enough to draw 1x1, 1x2 and 2x2, but not 2x1.
Patch by Simon Lees.
https://bugs.debian.org/639414
This reverts commit a104e317ce.
Breaks image loading in certain situations.
It seems that some loaders may return 0 even when load() "succeeds".
This appears to happen with the jpeg loader when not loading data
immediately (but only reading the header).
In this case jpeg_finish_decompress() exits via _JPEGFatalErrorHandler()
-> longjmp() causing the return code to be 0.
The fix reverted here is probably basically correct, but it will have to
wait until the loaders are fixed to behave properly.
Prevents tons of:
==10646== Conditional jump or move depends on uninitialised value(s)
==10646== at 0x4F7D30C: png_write_find_filter (pngwutil.c:2578)
==10646== by 0x4F7568F: png_write_row (pngwrite.c:827)
==10646== by 0x4F751B0: png_write_rows (pngwrite.c:587)
==10646== by 0x4D40C7D: save (loader_png.c:373)
==10646== by 0x1297084: __imlib_SaveImage (image.c:1282)
==10646== by 0x124252B: imlib_save_image (api.c:4615)
==10646== by 0x401990: main (imlib2_conv.c:74)
when trying to convert id:000134,src:000105,op:havoc,rep:32.
Fixes:
==14822== Conditional jump or move depends on uninitialised value(s)
==14822== at 0x4E08376: load (loader_tiff.c:285)
==14822== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==14822== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==14822== by 0x40F47B: feh_load_image (imlib.c:252)
==14822== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==14822== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==14822== by 0x421869: init_slideshow_mode (slideshow.c:62)
==14822== by 0x418F13: main (main.c:78)
==14822==
==14822== Conditional jump or move depends on uninitialised value(s)
==14822== at 0x4E083BC: load (loader_tiff.c:285)
==14822== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==14822== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==14822== by 0x40F47B: feh_load_image (imlib.c:252)
==14822== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==14822== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==14822== by 0x421869: init_slideshow_mode (slideshow.c:62)
==14822== by 0x418F13: main (main.c:78)
==14822==
when scaling id:000407,src:000226,op:havoc,rep:32 in feh.
Prevents invalid reads and unreasonably large memory allocations
with input/queue/id:000210,src:000114,op:int32,pos:3,val:be:+32,+cov:
==20321== Invalid read of size 1
==20321== at 0x1FCDB16: __imlib_ScaleAARGB (scale.c:1043)
==20321== by 0x1F9BF81: __imlib_RenderImage (rend.c:409)
==20321== by 0x1F0F82C: imlib_render_image_part_on_drawable_at_size (api.c:1886)
==20321== by 0x40CD75: gib_imlib_render_image_part_on_drawable_at_size (gib_imlib.c:231)
==20321== by 0x42C732: winwidget_render_image (winwidget.c:576)
==20321== by 0x417ACA: feh_event_handle_keypress (keyevents.c:598)
==20321== by 0x4190DE: feh_main_iteration (main.c:119)
==20321== by 0x418F45: main (main.c:82)
==20321== Address 0x3a12e034 is 12 bytes before a block of size 1,965,846,976 alloc'd
==20321== at 0x103D293: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==20321== by 0x5B3D1F1: load (loader_pnm.c:149)
==20321== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==20321== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==20321== by 0x40F47B: feh_load_image (imlib.c:252)
==20321== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==20321== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==20321== by 0x421869: init_slideshow_mode (slideshow.c:62)
==20321== by 0x418F13: main (main.c:78)
- Eliminate deprecated AC_TRY_CPP.
- Use pkg-config in stead of freetype-config to get freetype info.
- Eliminate my_includes/my_libs.
- Clean up include paths.
Drawing of the closing line could be skipped depending on the specific
vertex coordinates (and order).
Can't say that I undestand the code completely but this change seems
to fix the problem, and I don't think it can cause trouble.
Revert previous patch generated by badnull.cocci script, and apply the new one.
The main difference is that assert and assert-like functions are not touched
anymore.
SVN revision: 51650
Apply badzero.cocci, badnull.coci and badnull2.cocci
This should convert all cases where there's a comparison to NULL to simpler
forms. This patch applies the following transformations:
code before patch ||code after patch
===============================================================
return a == NULL; return !a;
return a != NULL; return !!a;
func(a == NULL); func(!a);
func(a != NULL); func(!!a);
b = a == NULL; b = !a;
b = a != NULL; b = !!a;
b = a == NULL ? c : d; b = !a ? c : d;
b = a != NULL ? c : d; b = a ? c : d;
other cases:
a == NULL !a
a != NULL a
SVN revision: 51487
Change calls to malloc + memset to calloc whenever an automatic conversion can
be done.
Possible candidates are not treated here, only the ones we can be sure the
conversion is safe.
SVN revision: 51078
* Remove vim modelines:
find . -name '*.[chx]' -exec sed -i '/\/\*$/ {N;N;/ \* vim:ts/d}' \{\} \;
find . -name '*.[chx]' -exec sed -i '/\/[\*\/] *vim:/d' \{\} \;
* Remove leading blank lines:
find . -name '*.[cxh]' -exec sed -i '/./,$!d'
If you use vim, use this in your .vimrc:
set ts=8 sw=3 sts=8 expandtab cino=>5n-3f0^-2{2(0W1st0
SVN revision: 50816
The notnull.cocci script from Coccinelle finds places where you check if a
variable is NULL, but it's known not to be NULL. The check can be safely
removed. For example, this code would be caught by notnull:
if (!var) return;
if (var && var->fld) { ... }
It's needless to check again if var is not NULL because if it's in fact NULL,
it would have returned on the previous "if". This commit removes all the
trivial places where this pattern happens. Another patch will be generated for
the more complex cases.
SVN revision: 50241
As far as I can tell this fixes building on x86_64 with e.g.
'./configure --enable-mmx CFLAGS=-m32" or "rpmbuild --target i386 ..."
without breaking anything.
SVN revision: 41667
imlib_context_disconnect_display() should be called when a display
connection is closed but the application continues using imlib2 with a
different display connection.
This is required to avoid to attempt to free cached GCs (in
__imlib_RenderImage) after the associated display connection has been
closed.
It is not unlikely that similar cleanups should be performed elsewhere
in this situation, but the __imlib_RenderImage GCs is the only case I
have found to cause trouble so far.
SVN revision: 35463