Support and General Use > Audio Playback, Database and Playlists

more than 10 "recent bookmarks" possible?

<< < (2/3) > >>

__builtin:
Just change line 46 of http://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/bookmark.c;hb=HEAD#l46 to read

--- Code: ---#define MAX_BOOKMARKS 100
--- End code ---
... or any other number you want, and (re)-compile+install.

[Saint]:
If I put on my speculation hat (as I'm not particularly interested in testing the exact limitations here), I would posit that at some point you're going to flood a stack if you increase this number to a ridiculous level.


[Saint]

fredex:
Saint would know a lot more than I, as I'm not a RB developer, but I AM a C programmer:

static char global_read_buffer[MAX_BOOKMARK_SIZE];
static char global_bookmark[MAX_BOOKMARK_SIZE];

these are the only two items in the file nick_p mentions that allocate space based on MAX_BOOKMARK_SIZE.

these two items don't go on the stack (or at least for a "normal" C compiler they don't, I'll assume the one used in RB follows that convention) since they are file-scoped static variables. they probably end up somewhere in the heap. therefore they shouldn't cause any problems with the stack (except: if the stack grows so large--from other causes-- that it collides with the heap, then you're in a world of hurt, so putting two larger arrays on the heap could make that collision more likely, given the fixed, small amounts of RAM these embedded systems contain.)

gevaerts:

--- Quote from: fredex on September 23, 2014, 09:43:55 AM ---Saint would know a lot more than I, as I'm not a RB developer, but I AM a C programmer:

--- End quote ---

Saint isn't :)


--- Quote ---static char global_read_buffer[MAX_BOOKMARK_SIZE];
static char global_bookmark[MAX_BOOKMARK_SIZE];

these are the only two items in the file nick_p mentions that allocate space based on MAX_BOOKMARK_SIZE.

these two items don't go on the stack (or at least for a "normal" C compiler they don't, I'll assume the one used in RB follows that convention) since they are file-scoped static variables. they probably end up somewhere in the heap. therefore they shouldn't cause any problems with the stack (except: if the stack grows so large--from other causes-- that it collides with the heap, then you're in a world of hurt, so putting two larger arrays on the heap could make that collision more likely, given the fixed, small amounts of RAM these embedded systems contain.)

--- End quote ---

There's also MAX_BOOKMARKS, but at first sight the same applies and I'm fairly sure your analysis is correct.

There's no stack/heap collision as such to fear for. Both these arrays and the stacks are allocated statically and have a fixed size. There's a regular check for stack overflow (every tick) using a sentinel value at the bottom of the stack.

Of course, there *is* such a thing as using so much memory there isn't enough left to buffer audio, but you're going to have to go for fairly insane values here to get to that point on most devices.

TAC109:
The only place MAX_BOOKMARKS is used is when adding a new bookmark to the bookmark file. In this process, the file is copied to a temp file, stopping when MAX_BOOKMARKS number of records have been copied, then the original bookmark file is deleted and the temp file renamed to the original bookmark file name.

There is no impact on stack or memory, only on disk storage space. And frankly, limiting the file to 10 entries of a maximum size of 350 bytes in these days of gigabyte drives is ridiculous.

Navigation

[0] Message Index

[#] Next page

[*] Previous page