On Thu, 9 Dec 2010 08:00:46 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> On Thu, Dec 9, 2010 at 12:32 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Thu, 09 Dec 2010 05:04:01 +0300 "Brett Nash" <n...@nash.id.au> said: > >> > +/* Why do this? Well PATH_MAX may vary from when eina itself is compiled > >> > + * to when the app using eina is compiled. exposing the path buffer > >> > below > >> > + * cant safely and portably vary based on how/when you compile. it > >> > should > >> > + * always be the same for both eina inside ANd for apps outside that use > >> > eina > >> > + * so define this ti 8192 minus ther other struct bits so that > >> > + * Eina_File_Direct_Info can take a nice round 2 pages. */ > >> > +#define EINA_PATH_MAX (8192 - (sizeof(size_t) * 3) - > >> > sizeof(Eina_File_Type)) > >> > >> Doesn't this logic only make sense if: > >> - You use external tracking for your mallocs, or > >> - You use a pool allocator? > >> > >> Since neither is true in the general case you've just made EINA_PATH_MAX > >> incompatible with every path max on the planet, in return for a gain > >> that > >> will won't happen for anyway. > > > > iot was either $define it to 4096 or choose another number (i just chose > > 8192 - some little bits). > > > >> Considering the only time it's used is INSIDE another structure... There > >> is never a gain. > >> > >> So the result is more complex, always incompatible, and never a gain. > > > > its SIMPLY changing the size of 1 struct element that actually never had a > > fixed known size anyway (as PATH_MAX may vary in its value between compiling > > eina itself and app using eina headers and compiling its own code), > > depending on what system headers where happened to have been included. look > > at the only thing using it. thats the only reason it exists. that 1 struct > > member. > > PATH_MAX there should not be important, it's some buffer size, as it's > read-only to the application, and the actual used size is in the > structure and that should be always used, the only problem so far is > that Raster added the "type" field AFTER the string... but he changed > that already, so doesn't matter now :-) that was a break anyway - but size should be fixed and known in an exposed data struct no matter what. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
