Age | Commit message (Collapse) | Author | Lines |
|
* Fix out of boundary access
The while-loop is not finished when pos is set to EXIF_MAX_DATA.
Instead, the loop continues and therefore tries to access data outside
of the array.
This is triggered when compiled with exif=1 and asan:
$ feh --draw-exif image.jpg
* Fixed formatting
No functional change but makes previous commit easier verifiable
(independent of tab space setup).
* Call break; instead of setting pos2 to a magic value
This is in line with the following else clause
* Another cosmetic adjustment
Co-authored-by: Daniel Friesel <derf@finalrewind.org>
|
|
|
|
Note that Imlib2 does not support JXL images out of the box. However, the
imlib2-jxl loader (https://github.com/alistair7/imlib2-jxl) does.
|
|
Fix some warnings from `gcc`.
|
|
|
|
Fixes https://github.com/derf/feh/issues/580
|
|
Note that Imlib2 does not support HEIC/HEIF images out of the box. However, the
imlib2-heic loader (https://github.com/vi/imlib2-heic) does.
Closes #579
|
|
|
|
|
|
|
|
This fixes two memory bugs that only manifest with exif=1 and long-running
slideshows.
* when feh loads an image, it writes exif data to file->ed. Previously, this
data was never free'd, causing a memory leak on subsequent loads of the same
file.
* As file->ed is never free'd, the accumulated EXIF data consumes a significant
amount of memory over time. with slideshow-delay = 10 and two days of
runtime, feh may exceed 1 GB of memory usage. If the slideshow is so large
that feh does not encounter the same image twice in this time, this is not
detected as a memory leak, as each EXIF data chunk is referenced from the
filelist.
See <https://github.com/derf/feh/issues/553> for details.
Closes #553
|
|
This works around a regression in Imlib2, which makes (un)loadable file
detection quite slow when handling e.g. large video files. See
<https://phab.enlightenment.org/T8739> and
<https://github.com/derf/feh/issues/505> for details.
Closes #505
|
|
Closes #532
|
|
|
|
|
|
Closes #521
|
|
feh_file_info_load is called even if file_info is already populated, so
the original file_info struct is never freed. This results in a leak of
~44 Byte for each subsequenc image load
|
|
|
|
|
|
|
|
|
|
|
|
Building feh 3.3 on CentOS 7 x86_64 warns `curl_quit_function` in `imlib.c` is unused:
```
cc -g -O2 -Wall -Wextra -pedantic -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -DHAVE_LIBCURL -DHAVE_VERSCMP -DHAVE_LIBXINERAMA -DHAVE_LIBEXIF -DPREFIX=\"/usr/local\" -DPACKAGE=\"feh\" -DVERSION=\"3.3\" -c -o imlib.o imlib.c
imlib.c:545:12: warning: ‘curl_quit_function’ defined but not used [-Wunused-function]
static int curl_quit_function(void *clientp, curl_off_t dltotal, curl_off_t dlnow, curl_off_t ultotal, curl_off_t ulnow)
^
```
The `curl_quit_function` code was added in response to pull [#435](https://github.com/derf/feh/pull/435)
In issue [#485](https://github.com/derf/feh/issues/485) a fellow CentOS 7 user had an error building feh because CentOS 7 is locked into an old version of libcurl. In the fix, a version guard was wrapped around the `curl_easy_setopt` call, but the rest of the code was unchanged.
Since I don't want to maintain a local build of libcurl, I looked at the curl docs and noticed there is an older callback which serves the same purpose: https://curl.haxx.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html
The difference between `PROGRESS` and `XFERINFO` is the callback's argument types, with `PROGRESS` using `double` and `XFERINFO` using `curl_off_t`: https://curl.haxx.se/libcurl/c/CURLOPT_XFERINFOFUNCTION.html
The callback's return value logic and use of `CURLOPT_NOPROGRESS` is the same.
For context, the latest libcurl RPM I'm getting from yum updates is `libcurl-7.29.0-54.el7_7.2.x86_64`. The "stable" versions of other distros may encounter similar issues. The CentOS 7 "End of Life" date is 2024-06-30 so you should hear the end of this by then, at least from us pesky CentOS users.
|
|
Closes #485
|
|
sig_exit may be changed by a signal handler, so its value should always be
read from RAM.
|
|
See also #435
|
|
|
|
|
|
|
|
ulteq-no-inplace-edit
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes non-random behaviour when randomizing file lists several times per
second.
Closes #349
|
|
Uses the camera-generated thumbnail to display RAW images that could otherwise not be loaded.
|
|
This introduces a new feh_should_ignore_image function which is called
at appropriate places in those modes to skip images which are loadable but
undesired.
|
|
* Prevents nasty loading loops
* Prevents zombie subprocesses
* Fixes the conversion timeout detection routine
|
|
|
|
This option allows you to change the default imlib2 image cache size of 4 MiB.
|
|
|
|
|
|
Similar to the `curl` command-line tool.
|
|
The check if buffer == NULL is always false, since buffer is an
autoamtic variable allocated when entering the function. What we
instead want to do is to check if the string is empty after the call to
exif_get_info(), since that means we could not read any exif
information.
When the code once more is enabled, I discovered that we need to copy
the information string into info_buf as well as into buffer, since it
is the former that is used to print the exif information on top of the
picture. Without this change, imlib warns about trying to write NULL
strings.
|
|
|
|
|
|
|
|
(cf #309)
|