I intended to check for enough space in buffer but this isn't
really doing it and it is making aa_bufsz slightly too big so
it's a possible buffer overflow.
Restore the old ALIGN_DOWN(..., 4) rounding in case it's important,
if not, then no harm done.
Change-Id: I904f255ac79a77d5328b44667502ceae8308e659
get rid of the magic buffer size and the whole name buffer
naming the buffers individually doesn't serve any real purpose
instead add a static string for all td buffers
Change-Id: I962a966456453e1b84bab6fec6f4df7cb075ef4e
It was possible for the tag tree's buflib move callback to turn a
null pointer non-null. The tagcache_search_clause->str can be null
for OR clauses. Also ensure that clauses are zeroed on allocation
to ensure garbage pointers don't creep in.
Change-Id: Ic823a8eecc501eeaa75798066521e427a9a89190
A couple of places use sizeof(int) for allocations and copying but
the indices are longs, which causes bugs in the simulator on 64-bit.
Change-Id: Ie101ac57d44217c4b1657cf0152c97e276bd7043
UBSan reports an avalanche of unaligned pointer bugs stemming from
hardcoded 4-byte alignments used in certain places. Use sizeof(long)
instead to align to the machine word size.
Change-Id: I28e505212462c5268afa24e95df3a103ac3e2213
These operations can only be used in limited circumstances and have
exactly one user. bufgettail especially seems of dubious value; how
often do you need to read N bytes from the end of a file without
changing the file position?
strip_tags() was the only function using them, to strip off ID3v1
and APE tags off the end of buffered tracks. This would save only
32-192 bytes per track -- if the container format uses APE/ID3v1.
It hardly seems worth the effort.
Change-Id: I8fc3c1408517eda6126e75e76d76daea904b50eb
According to the on screen instructions, any other button
should mean No.
More importantly, in my experience at least, the Select
"button", since it is touch-activated, can sometimes be
pressed by accident, especially when a warning screen
is displayed as a result of pressing that same button.
Change-Id: Ieeadfa8018b5df99605297bc47948a181c22dab4
np_file is a buffer of size MAX_PATH. After
removing only the file name component and
leaving the rest of the path, the
available space may not be sufficient
for appending another file name (possibly of
size MAX_PATH itself) to it.
This can occur after a file of acceptable
length is opened in ImageViewer, and you
then advance to another file whose path
(including the file name) is longer than
MAX_PATH.
Change-Id: Ideadd9451359bd5735bce92fca5d983e61f300e9
When the 'Album Art' setting was set to
'Prefer Image File' and neither image file
nor embedded artwork were found,
playback would check for files twice.
Change-Id: Ibe392928d58ec04103e2572124841724509bd859
flags were getting un-initialized memory
it really didn't matter with the flags getting initialized
anyway
But once I added a new flag that didn't explicitly
set or clear the flag at init well here we are
set flags to VP_DEFAULT_FLAGS in viewport_set_defaults()
add the flags variable to the default vp's set to 0
(it was already initialized to 0 by bss, make it explicit)
Change-Id: I3a9a062455b4cf66d2b8c70fdf05402a5c0c091c
Frequency, file size, and the codec are not stored
in the database and thus can’t be displayed in the
Playlist Viewer's Track Info screen when metadata
is only retrieved from the database.
Change-Id: I9e1d11c13ad8bf7b90b654ed78e4e7f763c30f8a
Eliminates flashing of slide right after launch or
when changing sorting on the M3K using the
volume buttons
Change-Id: Icd317e0b0d5b939269dc8dafd30d0c0f9daa5fd9
This plugin provides a menu for easily editing the root redirect file
on targets that support multiboot. You can select a new root from a
list of Rockbox installations detected on the filesystem or remove all
redirects to boot from the default location.
To avoid searching the whole filesystem, only subdirectories of the
volume roots are checked for valid installations. Only installations
that are compatible with the current player will be displayed.
Change-Id: I7dcbadfd97873b87817870e61d2ae37956d2da00
Allow a clean shutdown to end in either power off or reboot. Add a
new event SYS_REBOOT to signal it and sys_reboot() to trigger the
event. SYS_REBOOT signals a reboot request and should be listened
for alongside SYS_POWEROFF events.
Change-Id: I99ba7fb5feed2bb5a0a40a274e8466ad74fe3a43
its really painful needing to override global settings in order to change
some aspects of lists
this patch moves:
[scrollbar position, cursor type,
talk_menus, keyclick,
wrap around, scroll paginated]
to variables within the synclist, it also makes updating
after settings changes a necessity
I think I have the static synclists in core covered
(I think the one in gui/list-skinned can be left as is)
this patch allows easy modification these flags on the fly
Change-Id: Id0dcb8b05eb9ecd78929c0aff7678bf2ab4c70a7
The progress callback doesn't rate limit LCD updates, which causes
excessive slowdowns (up to 150x!) on some targets. Limiting updates
to 20fps solves the problem and should boost load speed across the
board, particularly for large images and animated GIFs that may run
the progress callback thousands of times.
Change-Id: Ia48924d4dcb24c1111509329581809be494d0165
In some circumstances it was possible for a bitmap to overflow its
buffer and overwrite the next handle. The easiest way to trigger it
is with a highly compressed JPEG that is decoded to a large bitmap.
Because the JPEG file size is used to determine how much to allocate
this would cause an obvious buffer overflow when the JPEG is smaller
than the decoded bitmap. Fix this by using the decoded bitmap size as
the allocation size. Some overhead must be added to deal with JPEGs,
but it will be freed once the image is loaded.
A less obvious possibility is the fact that add_handle() will allow
a handle to be added even if there's not enough space for the entire
allocation. This is generally beneficial because it allows the first
part of a file to be loaded while waiting for space to free up, but
for bitmaps it is not valid because the whole image is loaded at once.
Hence if there is not actually enough space in the buffer, the bitmap
load can again overflow the actual free space and overwrite the next
handle.
The buffering code supports an H_ALLOCALL flag for allocations that
need the free space available immediately, so use it for bitmaps to
avoid that bug.
load_image() had a sketchy-looking check for free space which stopped
me from triggering the bug with simple tests, but since guessing the
free space is obviously a bad idea when the caller *knows* how much
free space there really is, remove that guess and let the caller tell
load_image() the real deal.
Change-Id: If62a58759705d83c16ee5b50f26bcbccc3f6c01f
JPEG decoding requires additional space in the bitmap buffer beyond
what is needed for the decoded pixel data. Provide a way to estimate
how much overhead is needed.
The actual overhead is sizeof(struct jpeg) + decode_buf_size, where
the latter depends on the image size and JPEG encoding used. From my
testing decode_buf_size is normally pretty small (under 5 KiB) but
looking at the code it could be large in some cases, primarily with
large images, so 32 KiB seems to be a decent compromise. Someone who
knows better about JPEG should pick a better value if that's too big.
Using a constant is obviously not the most accurate but it seems to
be the simplest option for retrofitting to existing code.
Change-Id: I573b0abb8ca2d79e43f185010487f07226edb793
Not sure what the comment is talking about - signed overflow
is undefined behavior and we don't use -fwrapv or other flags
to make it defined. I can't see how a compiler could abuse it
here, but the overflow is nonetheless easily avoided.
Change-Id: Ibed6d7c0d841db2aa86b9d8ba4c6a0d08c413354
don't stop playback to alloc viewports for the keyboard
For the moment it doesn't make much difference
each vp takes about 40 bytes (double that in the sim?)
so not the end of the world 120 extra bytes
Change-Id: I482d7e3061cf9fb8065dc28bf62a6f830770f3c7
While the track number is limited to 99, I know of no documented
constraint on the value of offset minutes to 99.
As we are storing the millisecond offset as unsigned long, assuming
32 bit, we can allow 70,000 minutes (2^32 / 60000).
However, I've been unable to generate a test audio file 48 days long
under 2GB, so I've set the limit to 30,000 minutes.
In addition, this change reduces the maximum number of seconds to 59,
and frames to 74.
I've generated some silent test files with the filenames being
cue_[minutes].mp3
http://peskett.co.uk/rockbox/test_cues/
Change-Id: I3ca4468ebc88ba134c4e785e9395f90bf76941ac
allows items to be moved around with less code changes
remove scrolling I was not overly impressed with it
add test_kbd plugin
Change-Id: Ic183c7221bda9405891632704f3a7bbfd79bfe83
if you skip a track after the halfway point the scrobbler may double post
with slightly different timestamps but the same track info
take a crc of the non-unique part and check against the previously
written track
Change-Id: I676342c4cd76f632131d9cb6d9f7d2f59df357e6
The comment regarding Windows paths was fairly confusing as to
its intent. What the code is trying to do is replace the drive
letter with the volume containing the playlist, which appears
reasonable. The middle of the comment was devoted to explaining
why the code below was potentially incorrect which only served
to add to the confusion.
AFAICT the last volume specifier in a path will cause search to
start from the root of that volume, so any incorrect result can
be avoided by using the new function path_strip_last_volume().
Finally, add a comment at the top of the function that explains
what it does.
Change-Id: If4e4938801f2f81eb52f5d32b5461872995e5e83
Now offers sorting by:
- Album artist, then album name
- Album artist, then album year
- Album year
- Album name
Years are determined by the most recently
released track appearing on an album, if the
value differs between tracks.
On the M3K, instead of by going into Settings,
volume buttons can also be used for quickly
adjusting the current sorting
Change-Id: I2c50059617114fb418336c466fdd37415473ac7d
