rockbox/apps/gui/folder_select.c

636 lines
18 KiB
C
Raw Normal View History

/***************************************************************************
* __________ __ ___.
* Open \______ \ ____ ____ | | _\_ |__ _______ ___
* Source | _// _ \_/ ___\| |/ /| __ \ / _ \ \/ /
* Jukebox | | ( <_> ) \___| < | \_\ ( <_> > < <
* Firmware |____|_ /\____/ \___ >__|_ \|___ /\____/__/\_ \
* \/ \/ \/ \/ \/
*
* Copyright (C) 2012 Jonathan Gordon
* Copyright (C) 2012 Thomas Martitz
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
* * Copyright (C) 2021 William Wilgus
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
* KIND, either express or implied.
*
****************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "inttypes.h"
#include "config.h"
#include "core_alloc.h"
#include "filetypes.h"
#include "lang.h"
#include "language.h"
#include "list.h"
#include "plugin.h"
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
#include "splash.h"
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/* Define LOGF_ENABLE to enable logf output in this file */
//#define LOGF_ENABLE
#include "logf.h"
/*
* Order for changing child states:
* 1) expand folder (skip to 3 if empty, skip to 4 if cannot be opened)
* 2) collapse and select
* 3) unselect (skip to 1)
* 4) do nothing
*/
enum child_state {
EXPANDED,
SELECTED,
COLLAPSED,
EACCESS,
};
struct child {
char* name;
struct folder *folder;
enum child_state state;
};
struct folder {
char *name;
struct child *children;
struct folder* previous;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
uint16_t children_count;
uint16_t depth;
};
static char *buffer_front, *buffer_end;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
static struct
{
int32_t len; /* keeps count versus maxlen to give buffer full notification */
uint32_t val; /* hash of all selected items */
char buf[3];/* address used as identifier -- only \0 written to it */
char maxlen_exceeded; /*0,1*/
} hashed;
static inline void get_hash(const char *key, uint32_t *hash, int len)
{
*hash = crc_32(key, len, *hash);
}
static char* folder_alloc(size_t size)
{
char* retval;
/* 32-bit aligned */
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
size = ALIGN_UP(size, 4);
if (buffer_front + size > buffer_end)
{
return NULL;
}
retval = buffer_front;
buffer_front += size;
return retval;
}
static char* folder_alloc_from_end(size_t size)
{
if (buffer_end - size < buffer_front)
{
return NULL;
}
buffer_end -= size;
return buffer_end;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
#if 0
/* returns the buffer size required to store the path + \0 */
static int get_full_pathsz(struct folder *start)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
int reql = 0;
struct folder *next = start;
do
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
reql += strlen(next->name) + 1;
} while ((next = next->previous));
if (start->name[0] != '/') reql--;
if (--reql < 0) reql = 0;
return reql;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
#endif
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
static size_t get_full_path(struct folder *start, char *dst, size_t dst_sz)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
size_t pos = 0;
struct folder *prev, *cur = NULL, *next = start;
dst[0] = '\0'; /* for strlcat to do its thing */
/* First traversal R->L mutate nodes->previous to point at child */
while (next->previous != NULL) /* stop at the root */
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
#define PATHMUTATE() \
({ \
prev = cur; \
cur = next; \
next = cur->previous;\
cur->previous = prev; \
})
PATHMUTATE();
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/*swap the next and cur nodes to reverse direction */
prev = next;
next = cur;
cur = prev;
/* Second traversal L->R mutate nodes->previous to point back at parent
* copy strings to buf as they go by */
while (next != NULL)
{
PATHMUTATE();
pos = strlcat(dst, cur->name, dst_sz);
/* do not append slash to paths starting with slash */
if (cur->name[0] != '/')
pos = strlcat(dst, "/", dst_sz);
}
logf("get_full_path: (%d)[%s]", (int)pos, dst);
return pos;
#undef PATHMUTATE
}
/* support function for qsort() */
static int compare(const void* p1, const void* p2)
{
struct child *left = (struct child*)p1;
struct child *right = (struct child*)p2;
return strcasecmp(left->name, right->name);
}
static struct folder* load_folder(struct folder* parent, char *folder)
{
DIR *dir;
char fullpath[MAX_PATH];
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
struct dirent *entry;
int child_count = 0;
char *first_child = NULL;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
size_t len = 0;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
struct folder* this = (struct folder*)folder_alloc(sizeof(struct folder));
if (this == NULL)
goto fail;
if (parent)
{
len = get_full_path(parent, fullpath, sizeof(fullpath));
if (len >= sizeof(fullpath))
goto fail;
}
strmemccpy(&fullpath[len], folder, sizeof(fullpath) - len);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
logf("load_folder: [%s]", fullpath);
dir = opendir(fullpath);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (dir == NULL)
goto fail;
this->previous = parent;
this->name = folder;
this->children = NULL;
this->children_count = 0;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (parent)
this->depth = parent->depth + 1;
while ((entry = readdir(dir))) {
/* skip anything not a directory */
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if ((dir_get_info(dir, entry).attribute & ATTR_DIRECTORY) == 0) {
continue;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/* skip . and .. */
char *dn = entry->d_name;
if ((dn[0] == '.') && (dn[1] == '\0' || (dn[1] == '.' && dn[2] == '\0')))
continue;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/* copy entry name to end of buffer, save pointer */
len = strlen((char *)entry->d_name);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
char *name = folder_alloc_from_end(len+1); /*for NULL*/
if (name == NULL)
{
closedir(dir);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
goto fail;
}
memcpy(name, (char *)entry->d_name, len+1);
child_count++;
first_child = name;
}
closedir(dir);
/* now put the names in the array */
this->children = (struct child*)folder_alloc(sizeof(struct child) * child_count);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (this->children == NULL)
goto fail;
while (child_count)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
struct child *child = &this->children[this->children_count++];
child->name = first_child;
child->folder = NULL;
child->state = COLLAPSED;
while(*first_child++ != '\0'){};/* move to next name entry */
child_count--;
}
qsort(this->children, this->children_count, sizeof(struct child), compare);
return this;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
fail:
return NULL;
}
struct folder* load_root(void)
{
static struct child root_child;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/* reset the root for each call */
root_child.name = "/";
root_child.folder = NULL;
root_child.state = COLLAPSED;
static struct folder root = {
.name = "",
.children = &root_child,
.children_count = 1,
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
.depth = 0,
.previous = NULL,
};
return &root;
}
static int count_items(struct folder *start)
{
int count = 0;
int i;
for (i=0; i<start->children_count; i++)
{
struct child *foo = &start->children[i];
if (foo->state == EXPANDED)
count += count_items(foo->folder);
count++;
}
return count;
}
static struct child* find_index(struct folder *start, int index, struct folder **parent)
{
int i = 0;
*parent = NULL;
while (i < start->children_count)
{
struct child *foo = &start->children[i];
if (i == index)
{
*parent = start;
return foo;
}
i++;
if (foo->state == EXPANDED)
{
struct child *bar = find_index(foo->folder, index - i, parent);
if (bar)
{
return bar;
}
index -= count_items(foo->folder);
}
}
return NULL;
}
static const char * folder_get_name(int selected_item, void * data,
char * buffer, size_t buffer_len)
{
struct folder *root = (struct folder*)data;
struct folder *parent;
struct child *this = find_index(root, selected_item , &parent);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
char *buf = buffer;
if ((int)buffer_len > parent->depth)
{
int i = parent->depth;
while(--i > 0) /* don't indent the parent /folders */
*buf++ = '\t';
}
*buf = '\0';
strlcat(buffer, this->name, buffer_len);
if (this->state == EACCESS)
{ /* append error message to the entry if unaccessible */
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
size_t len = strlcat(buffer, " ( ", buffer_len);
if (buffer_len > len)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
snprintf(&buffer[len], buffer_len - len, str(LANG_READ_FAILED), ")");
}
}
return buffer;
}
static enum themable_icons folder_get_icon(int selected_item, void * data)
{
struct folder *root = (struct folder*)data;
struct folder *parent;
struct child *this = find_index(root, selected_item, &parent);
switch (this->state)
{
case SELECTED:
return Icon_Cursor;
case COLLAPSED:
return Icon_Folder;
case EXPANDED:
return Icon_Submenu;
case EACCESS:
return Icon_Questionmark;
}
return Icon_NOICON;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
static int child_set_state_expand(struct child *this, struct folder *parent)
{
int newstate = EACCESS;
if (this->folder == NULL)
this->folder = load_folder(parent, this->name);
if (this->folder != NULL)
{
if(this->folder->children_count == 0)
newstate = SELECTED;
else
newstate = EXPANDED;
}
this->state = newstate;
return newstate;
}
static int folder_action_callback(int action, struct gui_synclist *list)
{
struct folder *root = (struct folder*)list->data;
struct folder *parent;
struct child *this = find_index(root, list->selected_item, &parent), *child;
int i;
if (action == ACTION_STD_OK)
{
switch (this->state)
{
case EXPANDED:
this->state = SELECTED;
break;
case SELECTED:
this->state = COLLAPSED;
break;
case COLLAPSED:
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
child_set_state_expand(this, parent);
break;
case EACCESS:
/* cannot open, do nothing */
return action;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
action = ACTION_REDRAW;
}
else if (action == ACTION_STD_CONTEXT)
{
switch (this->state)
{
case EXPANDED:
for (i = 0; i < this->folder->children_count; i++)
{
child = &this->folder->children[i];
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
switch (child->state)
{
case SELECTED:
case EXPANDED:
child->state = COLLAPSED;
break;
case COLLAPSED:
child->state = SELECTED;
break;
case EACCESS:
break;
}
}
break;
case SELECTED:
case COLLAPSED:
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (child_set_state_expand(this, parent) != EACCESS)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
for (i = 0; i < (this->folder->children_count); i++)
{
child = &this->folder->children[i];
child->state = SELECTED;
}
}
break;
case EACCESS:
/* cannot open, do nothing */
return action;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
action = ACTION_REDRAW;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (action == ACTION_REDRAW)
list->nb_items = count_items(root);
return action;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
static struct child* find_from_filename(const char* filename, struct folder *root)
{
if (!root)
return NULL;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
const char *slash = strchr(filename, '/');
struct child *this;
/* filenames beginning with a / are specially treated as the
* loop below can't handle them. they can only occur on the first,
* and not recursive, calls to this function.*/
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (filename[0] == '/') /* in the loop nothing starts with '/' */
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
logf("find_from_filename [%s]", filename);
/* filename begins with /. in this case root must be the
* top level folder */
this = &root->children[0];
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (filename[1] == '\0')
{ /* filename == "/" */
return this;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
else /* filename == "/XXX/YYY". cascade down */
goto cascade;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
for (int i = 0; i < root->children_count; i++)
{
this = &root->children[i];
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/* when slash == NULL n will be really large but \0 stops the compare */
if (strncasecmp(this->name, filename, slash - filename) == 0)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (slash == NULL)
{ /* filename == XXX */
return this;
}
else
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
goto cascade;
}
}
return NULL;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
cascade:
/* filename == XXX/YYY. cascade down */
child_set_state_expand(this, root);
while (slash[0] == '/') slash++; /* eat slashes */
return find_from_filename(slash, this->folder);
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
static int select_paths(struct folder* root, const char* filenames)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/* Takes a list of filenames in a ':' delimited string
splits filenames at the ':' character loads each into buffer
selects each file in the folder list
if last item or only item the rest of the string is copied to the buffer
*End the last item WITHOUT the ':' character /.rockbox/eqs:/.rockbox/wps\0*
*/
char buf[MAX_PATH];
const int buflen = sizeof(buf);
const char *fnp = filenames;
const char *lastfnp = fnp;
const char *sstr;
off_t len;
while (fnp)
{
fnp = strchr(fnp, ':');
if (fnp)
{
len = fnp - lastfnp;
fnp++;
}
else /* no ':' get the rest of the string */
len = strlen(lastfnp);
sstr = lastfnp;
lastfnp = fnp;
if (len <= 0 || len + 1 >= buflen)
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
continue;
strmemccpy(buf, sstr, len + 1);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
struct child *item = find_from_filename(buf, root);
if (item)
item->state = SELECTED;
}
return 0;
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
static void save_folders_r(struct folder *root, char* dst, size_t maxlen, size_t buflen)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
size_t len;
struct folder *curfolder;
char* name;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
for (int i = 0; i < root->children_count; i++)
{
struct child *this = &root->children[i];
if (this->state == SELECTED)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (this->folder == NULL)
{
curfolder = root;
name = this->name;
logf("save_folders_r: this->name[%s]", name);
}
else
{
curfolder = this->folder->previous;
name = this->folder->name;
logf("save_folders_r: this->folder->name[%s]", name);
}
len = get_full_path(curfolder, buffer_front, buflen);
if (len + 2 >= buflen)
continue;
len += snprintf(&buffer_front[len], buflen - len, "%s:", name);
logf("save_folders_r: [%s]", buffer_front);
if (dst != hashed.buf)
{
int dlen = strlen(dst);
if (dlen + len >= maxlen)
continue;
strmemccpy(&dst[dlen], buffer_front, maxlen - dlen);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
}
else
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (hashed.len + len >= maxlen)
{
hashed.maxlen_exceeded = 1;
continue;
}
get_hash(buffer_front, &hashed.val, len);
hashed.len += len;
}
}
else if (this->state == EXPANDED)
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
save_folders_r(this->folder, dst, maxlen, buflen);
}
}
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
static uint32_t save_folders(struct folder *root, char* dst, size_t maxlen)
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
hashed.len = 0;
hashed.val = 0;
hashed.maxlen_exceeded = 0;
size_t len = buffer_end - buffer_front;
dst[0] = '\0';
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
save_folders_r(root, dst, maxlen, len);
len = strlen(dst);
/* fix trailing ':' */
if (len > 1) dst[len-1] = '\0';
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
/*Notify - user will probably not see save dialog if nothing new got added*/
if (hashed.maxlen_exceeded > 0) splash(HZ *2, ID2P(LANG_SHOWDIR_BUFFER_FULL));
return hashed.val;
}
bool folder_select(char* setting, int setting_len)
{
struct folder *root;
struct simplelist_info info;
size_t buf_size;
buffer_front = plugin_get_buffer(&buf_size);
buffer_end = buffer_front + buf_size;
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
logf("%d bytes free", (int)(buffer_end - buffer_front));
root = load_root();
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
logf("folders in: %s", setting);
/* Load previous selection(s) */
select_paths(root, setting);
/* get current hash to check for changes later */
uint32_t hash = save_folders(root, hashed.buf, setting_len);
simplelist_info_init(&info, str(LANG_SELECT_FOLDER),
count_items(root), root);
info.get_name = folder_get_name;
info.action_callback = folder_action_callback;
info.get_icon = folder_get_icon;
simplelist_show_list(&info);
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
logf("%d bytes free", (int)(buffer_end - buffer_front));
/* done editing. check for changes */
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
if (hash != save_folders(root, hashed.buf, setting_len))
{ /* prompt for saving changes and commit if yes */
if (yesno_pop(ID2P(LANG_SAVE_CHANGES)))
{
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
save_folders(root, setting, setting_len);
settings_save();
folder_select.c partial rewrite -- remove static, add full notification | with some code refactoring we can eliminate the static char buffer in get_full_path() I'm guessing making the functions recursive prompted the static buffer I don't see any reason we can't just pass the same buffer | During tested I noted failure after buffer was full -- splash added for buffer full notification added some logic to not add partial entries and try to find a | selected item that will fit in the remaing buffer ------------------------------------------------------------------------ While looking through the source I noticed a few potential pitfalls with the current code. Namely the stack allocated temporary buffer sized to setting_len. I also noted the rigid vect[32] with the timeless -- /* 32 separate folders should be Enough For Everybody(TM) */ and decided to make it a bit more robust The saved items are hashed with crc32 on all the paths and a hashed_len is kept to aid in the buffer full message before the user actually goes to save the changes (assuming they even get the message) In the old code, buffer might be the same since it ran out of space and didn't get their later selections the hashed_len could easily be turned into a way to get a needed buffer size as well for someone in the future just pass a really large maxlen I made get_full_path non recursive since it liked to blow the stack while embedded in all the other recursive calls making it a pain to debug (the real reason the buffer was static?) traverse first from the current folder to root mutating the parent pointers to point at the previous child next traverse back to the folder unmutating & taking names on the way Folder depth is now uint16 65535 levels is probably excessive children_count is also uint16 as well I made the first folders below root '/' stay below root instead of shifting since the horizontal real estate is limited slightly smaller than it began but hopefully faster & more reliable Change-Id: I348f61baf865cccdeacddfd9d50641a882e890fc
2021-11-01 04:22:22 +00:00
logf("folders out: %s", setting);
return true;
}
}
return false;
}