On Sunday 13 July 2008, Kenneth Lerman wrote: > > Why do you need to increase the size of the array ? > > My plan for GWiz is that each wizard is contained in a separate > directory.
Perhaps a relative path (or appending to a gwiz_root) would work as well.. > > Are you aware of the wider implications of doing so ? > > Aside from using more memory, I'm not aware of any. I hope that those > who are aware of other implications will clue me in. sizeof(char) * PATH_MAX for each process reading from the task status plus an additional sizeof(char) * PATH_MAX * 4 (if the data is encoded) for the master buffer. Then there is the time taken to encode/copy/decode the data. > > How many users use path/file names larger than 255 char ? > > In this context, none. If they did, it wouldn't work. How many would > like to? At least one. At any rate, it is rather arbitrary to make the > maximum length the same as the length of a line. And it is clearly bad > form to use the same #define for both. Is it any worse than allocating 4K of space when the string may only use 30 bytes ? Suggestion: include <limits.h> and use _POSIX_PATH_MAX Alternative: Leave the task_stat struct as is, and _IF_ it becomes an issue at some point for a significant number of users, increase the size by a modest amount. Internally, feel free to use std::string rather than a fixed size buffer. --- Paul. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
