This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Ok, I've been poking around in path_conv and related stuff. Getting rid of the large in-object arrays does work around the bug in gcc - but I don't know if I'd catch them all manually - I still have a bust .dll when I bump the internal path size up. What I'd like to do is alter the path conversion functions to allocate a a new buffer when appropriate, rather than take a fixed size buffer as parameter. I've written a trivial string memory management class as part of my testing here, which I'd use to manage this. At the moment, all the path conversion calls assume the same fixed buffer size, throughout cygwin. Having functions that decide on the length of data needed allocate an appropriate buffer would do two things: *) Allow incremental conversion - which would give rise to a stream of small patches, rather than a huge non decomposable patch. *) reduce stack pressure. Thoughts? Unfortunately, I don't know what issues are gcc caused, and what are unrelated at this point :[. Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |