Re: For masochists: the leap o faith
On Fri, 2003-11-21 at 21:25, Corinna Vinschen wrote: On Fri, Nov 21, 2003 at 07:58:36AM +1100, Robert Collins wrote: I would prefer to change PATH_MAX and MAXPATHLEN to an arbitrary big value as, e. g. the same as on Linux, 4096, or even the biggest possible plus one: 32768. The latter is probably the better value. So my choice is a) Ok. What should we set CYG_MAX_PATH to initially then? I think we should start at 4K, until we've seen whether there are any stack size issues. I think we should get rid of static buffers in most cases. Some of them might be kept in place, returning to MAX_PATH, the others should use another technique, like alloca. As I see it, CYG_MAX_PATH should be just a temporary measure. Stack issues, not static buffers - or did you mean 'stack' buffers? Anyway, yes, we should tune each individual thing to an appropriate strategy - self managing objects, alloc etc. However, CYG_MAX_PATH is simply decoupling the win32 ANSI path limit from our internal path limit. If and when we don't have an effective internal limit anymore, sure it can go. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: For masochists: the leap o faith
On Sat, Nov 22, 2003 at 08:44:49PM +1100, Robert Collins wrote: On Fri, 2003-11-21 at 21:25, Corinna Vinschen wrote: On Fri, Nov 21, 2003 at 07:58:36AM +1100, Robert Collins wrote: I would prefer to change PATH_MAX and MAXPATHLEN to an arbitrary big value as, e. g. the same as on Linux, 4096, or even the biggest possible plus one: 32768. The latter is probably the better value. So my choice is a) Ok. What should we set CYG_MAX_PATH to initially then? I think we should start at 4K, until we've seen whether there are any stack size issues. I think we should get rid of static buffers in most cases. Some of them might be kept in place, returning to MAX_PATH, the others should use another technique, like alloca. As I see it, CYG_MAX_PATH should be just a temporary measure. Stack issues, not static buffers - or did you mean 'stack' buffers? 'Statically sized' Anyway, yes, we should tune each individual thing to an appropriate strategy - self managing objects, alloc etc. However, CYG_MAX_PATH is simply decoupling the win32 ANSI path limit from our internal path limit. If and when we don't have an effective internal limit anymore, sure it can go. Yup, that's what I meant. It doesn't hurt to check the occurences of CYG_MAX_PATH now, if there isn't a simple way to get around without it. Other than that, I think the right limit is 32K as I already wrote in my first reply (see above), not something less than that. Using some arbitrary number like 4K only results in headaches at a point where you had never expected it. The difference to Linux is, that 4K is the real limit on Linux, while our limit is 32K. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sat, 2003-11-22 at 21:59, Corinna Vinschen wrote: However, CYG_MAX_PATH is simply decoupling the win32 ANSI path limit from our internal path limit. If and when we don't have an effective internal limit anymore, sure it can go. Yup, that's what I meant. It doesn't hurt to check the occurences of CYG_MAX_PATH now, if there isn't a simple way to get around without it. Other than that, I think the right limit is 32K as I already wrote in my first reply (see above), not something less than that. Using some arbitrary number like 4K only results in headaches at a point where you had never expected it. The difference to Linux is, that 4K is the real limit on Linux, while our limit is 32K. Ok. Well, once we have the bugs ironed out, lets bump PATH_MAX to 32K, and let the recompilation begin :}. I'll probably put a few test binaries together in a setup.exe repository - ash, bash, tar, gzip as a minimum for folk to play with, when the patch gets closer to full completion. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: For masochists: the leap o faith
On Fri, Nov 21, 2003 at 07:58:36AM +1100, Robert Collins wrote: On Mon, 2003-11-17 at 21:56, Corinna Vinschen wrote: On Sun, Nov 16, 2003 at 08:10:08AM +1100, Robert Collins wrote: We have two choices (no particular order of preference): a) make MAX_PATH and posix friends the maximum length path cygwin will accept/return. Return ENAMETOOLONG on path calls on win9x, or winnt FAT[32] calls. Update pathconf to return appropriate values. b) blow away MAX_PATH and MAXPATHLEN so that programs using cygwin fallback to pathconf, or 'good enough for me' static arrays. Update pathconf to return appropriate values. Well, I guess you meant PATH_MAX here. Yes, of course. I would prefer to change PATH_MAX and MAXPATHLEN to an arbitrary big value as, e. g. the same as on Linux, 4096, or even the biggest possible plus one: 32768. The latter is probably the better value. So my choice is a) Ok. What should we set CYG_MAX_PATH to initially then? I think we should start at 4K, until we've seen whether there are any stack size issues. I think we should get rid of static buffers in most cases. Some of them might be kept in place, returning to MAX_PATH, the others should use another technique, like alloca. As I see it, CYG_MAX_PATH should be just a temporary measure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sat, 2003-11-15 at 09:07, Christopher Faylor wrote: This problem is fixed in the gcc cvs trunk. I've asked Danny and Gerrit about backporting the fix to 3.3.2. It should be trivial to do so. Any word on this? Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: For masochists: the leap o faith
On Fri, Nov 21, 2003 at 07:43:09AM +1100, Robert Collins wrote: On Sat, 2003-11-15 at 09:07, Christopher Faylor wrote: This problem is fixed in the gcc cvs trunk. I've asked Danny and Gerrit about backporting the fix to 3.3.2. It should be trivial to do so. Any word on this? I backported it into cygwin's 3.3.2 branch but I haven't seen Gerrit around for a while to generate a new gcc. cgf
ATTN Gerrit (Was Re: For masochists: the leap o faith)
On Fri, 2003-11-21 at 08:05, Christopher Faylor wrote: I backported it into cygwin's 3.3.2 branch but I haven't seen Gerrit around for a while to generate a new gcc. Cool, thanks. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: ATTN Gerrit (Was Re: For masochists: the leap o faith)
Hello Robert, On 20. November 2003 at 22:09 you wrote: RC On Fri, 2003-11-21 at 08:05, Christopher Faylor wrote: I backported it into cygwin's 3.3.2 branch but I haven't seen Gerrit around for a while to generate a new gcc. I'm out of office and it is a lot of work to do here in my company. I'll try to get 3.3.2 ready over the weekend. -- Mit freundlichen Grüssen Gerrit P. Haase mailto:[EMAIL PROTECTED]
Re: ATTN Gerrit (Was Re: For masochists: the leap o faith)
On Fri, 2003-11-21 at 10:35, Gerrit P. Haase wrote: Hello Robert, On 20. November 2003 at 22:09 you wrote: RC On Fri, 2003-11-21 at 08:05, Christopher Faylor wrote: I backported it into cygwin's 3.3.2 branch but I haven't seen Gerrit around for a while to generate a new gcc. I'm out of office and it is a lot of work to do here in my company. I'll try to get 3.3.2 ready over the weekend. Cool - thank you. If I can help, let me know. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: For masochists: the leap o faith
On Mon, 2003-11-17 at 21:56, Corinna Vinschen wrote: On Sun, Nov 16, 2003 at 08:10:08AM +1100, Robert Collins wrote: We have two choices (no particular order of preference): a) make MAX_PATH and posix friends the maximum length path cygwin will accept/return. Return ENAMETOOLONG on path calls on win9x, or winnt FAT[32] calls. Update pathconf to return appropriate values. b) blow away MAX_PATH and MAXPATHLEN so that programs using cygwin fallback to pathconf, or 'good enough for me' static arrays. Update pathconf to return appropriate values. Well, I guess you meant PATH_MAX here. Yes, of course. I would prefer to change PATH_MAX and MAXPATHLEN to an arbitrary big value as, e. g. the same as on Linux, 4096, or even the biggest possible plus one: 32768. The latter is probably the better value. So my choice is a) Ok. What should we set CYG_MAX_PATH to initially then? I think we should start at 4K, until we've seen whether there are any stack size issues. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: For masochists: the leap o faith
On Sun, Nov 16, 2003 at 08:10:08AM +1100, Robert Collins wrote: Chris has noted that posixly correct behaviour and common practice may diverge. I think for this scenario, that posix behaviour allows the most accurate representation of the variety programs may encounter on cygwin at runtime. Therefore we'll get the best results (and perhaps uncover a few portability bugs) going that way. We have two choices (no particular order of preference): a) make MAX_PATH and posix friends the maximum length path cygwin will accept/return. Return ENAMETOOLONG on path calls on win9x, or winnt FAT[32] calls. Update pathconf to return appropriate values. b) blow away MAX_PATH and MAXPATHLEN so that programs using cygwin fallback to pathconf, or 'good enough for me' static arrays. Update pathconf to return appropriate values. Well, I guess you meant PATH_MAX here. Just to reiterate, MAX_PATH is a Windows specific constant, giving a maximum size for path names when using ASCII mode. Even this MAX_PATH constant doesn't actually reflect the maximum path length possible in all cases: CreateDirectory for instance can only create directories with a path length up to 248 characters. So even on native Windows, the constant is used as an upper limit, e. g. usable for static buffer sizes in applications. Having said that, however, you must not change MAX_PATH. I would prefer to change PATH_MAX and MAXPATHLEN to an arbitrary big value as, e. g. the same as on Linux, 4096, or even the biggest possible plus one: 32768. The latter is probably the better value. So my choice is a) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sat, 2003-11-15 at 15:43, Christopher Faylor wrote: Yes, I've already (obviously?) been to SUSv3. I wasn't talking about standards. I was talking about common practice. If you have a common practice web site that you want to show me then that might be a convincing argument. Otherwise, I'll have to fall back on my personal UNIX experience. http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2003-04/msg00600.html Part of a thread on this in another project. Seems like the hurd follows the no-PATH_MAX, use pathconf() always approach. Which means that everything thats portable to the hurd, will Do The Right Thing, if we eliminate the PATH_MAX and MAXPATHLEN defines. In my digging, I found that PATH_MAX, if defined, MUST be the largest path length possible. Presumably thats so that programs with static buffers won't run into trouble. Either way(increase PATH_MAX or remove it), to support longer paths, we'll need to make the change and transition to it. So, as I see it the question for you is : which route do you prefer? Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: For masochists: the leap o faith
On Sat, Nov 15, 2003 at 07:07:26PM +1100, Robert Collins wrote: On Sat, 2003-11-15 at 15:43, Christopher Faylor wrote: Yes, I've already (obviously?) been to SUSv3. I wasn't talking about standards. I was talking about common practice. If you have a common practice web site that you want to show me then that might be a convincing argument. Otherwise, I'll have to fall back on my personal UNIX experience. http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2003-04/msg00600.html Part of a thread on this in another project. Seems like the hurd follows the no-PATH_MAX, use pathconf() always approach. Which means that everything thats portable to the hurd, will Do The Right Thing, if we eliminate the PATH_MAX and MAXPATHLEN defines. In my digging, I found that PATH_MAX, if defined, MUST be the largest path length possible. Presumably thats so that programs with static buffers won't run into trouble. I mention common practice and you point me at a discussion which talks about the Hurd??? The Hurd? Wow. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sat, Nov 15, 2003 at 11:45:34AM -0500, Christopher Faylor wrote: On Sat, Nov 15, 2003 at 07:07:26PM +1100, Robert Collins wrote: On Sat, 2003-11-15 at 15:43, Christopher Faylor wrote: Yes, I've already (obviously?) been to SUSv3. I wasn't talking about standards. I was talking about common practice. If you have a common practice web site that you want to show me then that might be a convincing argument. Otherwise, I'll have to fall back on my personal UNIX experience. http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2003-04/msg00600.html Part of a thread on this in another project. Seems like the hurd follows the no-PATH_MAX, use pathconf() always approach. Which means that everything thats portable to the hurd, will Do The Right Thing, if we eliminate the PATH_MAX and MAXPATHLEN defines. In my digging, I found that PATH_MAX, if defined, MUST be the largest path length possible. Presumably thats so that programs with static buffers won't run into trouble. I mention common practice and you point me at a discussion which talks about the Hurd??? The Hurd? Wow. Btw, I've moved this discussion here from cygwin-patches because we are talking about a change which could impact a number of people. Robert is submitting patches which increase the maximum path length for NT-class systems. My concern is that PATH_MAX will be increased for this change. It will no longer reflect the win32 api MAX_PATH value and I was wondering if that would cause problems for existing applications. I thought the cygwin mailing list would be a wider audience for this type of thing than cygwin-patches, especially since no one is offering opinions in cygwin-patches. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sat, 15 Nov 2003, Christopher Faylor wrote: Btw, I've moved this discussion here from cygwin-patches because we are talking about a change which could impact a number of people. Robert is submitting patches which increase the maximum path length for NT-class systems. My concern is that PATH_MAX will be increased for this change. It will no longer reflect the win32 api MAX_PATH value and I was wondering if that would cause problems for existing applications. Would this affect gcc -mno-cygwin? That would seem bad. I thought the cygwin mailing list would be a wider audience for this type of thing than cygwin-patches, especially since no one is offering opinions in cygwin-patches. Well, since your soliciting opinions... I don't have much of one other than I'd really prefer to keep PATH_MAX/MAX_PATH and define them to the largest allowable path so they can still be used for sizing arrays. I don't really care if that lenght is not always supported. I would assume that any application that goes to the trouble of doing something other than bailing with an error in that case should actually use pathconf. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sat, Nov 15, 2003 at 01:09:00PM -0600, Brian Ford wrote: On Sat, 15 Nov 2003, Christopher Faylor wrote: Btw, I've moved this discussion here from cygwin-patches because we are talking about a change which could impact a number of people. Robert is submitting patches which increase the maximum path length for NT-class systems. My concern is that PATH_MAX will be increased for this change. It will no longer reflect the win32 api MAX_PATH value and I was wondering if that would cause problems for existing applications. Would this affect gcc -mno-cygwin? That would seem bad. No. It should have no effect. Different header files. I thought the cygwin mailing list would be a wider audience for this type of thing than cygwin-patches, especially since no one is offering opinions in cygwin-patches. Well, since your soliciting opinions... I don't have much of one other than I'd really prefer to keep PATH_MAX/MAX_PATH and define them to the largest allowable path so they can still be used for sizing arrays. I don't really care if that lenght is not always supported. Ok. That was one plan. I was concerned that a program might be assuming that since it had carefully checked that a path was = PATH_MAX, everything was fine when on a Windows 98 system, it could conceivably fail. I know that this isn't exactly a 100% safe and sanctioned use of PATH_MAX but it seems like the possibility exists that working code could be broken by this change. Robert seems to be leaning towards removing the PATH_MAX define entirely now, however. I would assume that any application that goes to the trouble of doing something other than bailing with an error in that case should actually use pathconf. That's the way I'd write my code but I'm not certain that all of the currently running code is so robust. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sat, 15 Nov 2003, Christopher Faylor wrote: On Sat, Nov 15, 2003 at 01:09:00PM -0600, Brian Ford wrote: Well, since your soliciting opinions... I don't have much of one other than I'd really prefer to keep PATH_MAX/MAX_PATH and define them to the largest allowable path so they can still be used for sizing arrays. I don't really care if that lenght is not always supported. Ok. That was one plan. I was concerned that a program might be assuming that since it had carefully checked that a path was = PATH_MAX, everything was fine when on a Windows 98 system, it could conceivably fail. I know that this isn't exactly a 100% safe and sanctioned use of PATH_MAX but it seems like the possibility exists that working code could be broken by this change. Working buggy code, yes. I wouldn't sweat it. I would be simple to fix. Robert seems to be leaning towards removing the PATH_MAX define entirely now, however. Like I said before, this doesn't seem like a very good idea. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: For masochists: the leap o faith
On Sun, 2003-11-16 at 06:09, Brian Ford wrote: On Sat, 15 Nov 2003, Christopher Faylor wrote: Btw, I've moved this discussion here from cygwin-patches because we are talking about a change which could impact a number of people. Robert is submitting patches which increase the maximum path length for NT-class systems. My concern is that PATH_MAX will be increased for this change. It will no longer reflect the win32 api MAX_PATH value and I was wondering if that would cause problems for existing applications. Well, since your soliciting opinions... I don't have much of one other than I'd really prefer to keep PATH_MAX/MAX_PATH and define them to the largest allowable path so they can still be used for sizing arrays. I don't really care if that lenght is not always supported. MAX_PATH -will not- change. It's a win32 define, not a cygwin or posix define. If you want to use static arrays, and don't care about supporting the full system facilities: just use an arbitrary figure that is big enough for your users. Remember: 640K is all you need. I would assume that any application that goes to the trouble of doing something other than bailing with an error in that case should actually use pathconf. Right. The posix specs (a couple of links to opengroup are in the thread in cygwin-patches) place the following limits: 1) if defined PATH_MAX must be the largest value [f]pathconf will return. 2) if PATH_MAX isn't defined, and [f]pathconf doesn't have an arbitrary limit, then calling pathconf on _PC_PATH_MAX where no limit exists can return -1 and clear errno. For us calling pathconf _PC_PATH_MAX on / , we can return the current global maximum. (Note that the global maximum we can support is actually the DOS maximum path length + the path from the cygwin mount table. I.e. if you mount d:\[250 times]\[250 times]\[250 time] at /foo, the max path from /foo is -NOT- CYG_MAX_PATH (the new internal buffer size), but is rather: CYG_MAX_PATH - 4 (the \\?\ prefix) - 1 (NULL) - len (d:\[250 times]\[250 times]\[250 times] = ~= CYG_MAX_PATH - 760. encouraging the use of MAX_PATH when we have this underlying variability is not a good thing IMO. Chris has noted that posixly correct behaviour and common practice may diverge. I think for this scenario, that posix behaviour allows the most accurate representation of the variety programs may encounter on cygwin at runtime. Therefore we'll get the best results (and perhaps uncover a few portability bugs) going that way. We have two choices (no particular order of preference): a) make MAX_PATH and posix friends the maximum length path cygwin will accept/return. Return ENAMETOOLONG on path calls on win9x, or winnt FAT[32] calls. Update pathconf to return appropriate values. b) blow away MAX_PATH and MAXPATHLEN so that programs using cygwin fallback to pathconf, or 'good enough for me' static arrays. Update pathconf to return appropriate values. I've no particular preference: either will support the change reasonably well. I'm mainly keen to see the thing inside cygwin, able to be used and understood. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: For masochists: the leap o faith
Robert Collins wrote: Ok, so this it for tonight, my bed is calling me. If playing with this, be sure to: rebuild libc as well as cygwin1.dll. be setup to debug cygwin1.dll. I don't *think* I've changed the size of the shared stuff, but then again, I'm pretty tired, so I'll believe anything right now. My plan is to unbreak cygwin tomorrow, and then work through the list of potentially update-requiring API calls: Turns out, that we still have a bug with gcc, where registeres are trashed when alloca is used to allocate large stack objects. I posted a test case to the developers list when we where working on -O3 support ?two? years back - it looks like the same issue. So, I've dropped CYG_MAX_PATH to 512 in winsup.h, and that makes the dll usable. There is an issue with the win32 responses on loong files - but at least we can continue progressing. So, Chris, are there any parts you've seen so far, that you've be happy to ok (i.e. the MAX_PATH-CYG_MAX_PATH rename), or the global search and replaces to the thunk functions? As far as applications maing assumptions, unix file systems don't guarantee PATH_MAX: thats an upper limit of the OS, applications are expected to be able to handle to up to PATH_MAX... but can't expect the OS to do so in every case. Now, for global use of an A or W function, Chris' utf patch which I just ran into digging into a INVALID_NAME error, also chose at runtime. I can easily alter IOThunkState to always use W if available, and then check a cached flag from then on in. I really think that the current overhead will be low enough to be a non-issue though. Rob
Re: For masochists: the leap o faith
Christopher Faylor wrote: On Sat, Nov 15, 2003 at 07:31:42AM +1100, Robert Collins wrote: I posted a test case to the developers list when we where working on -O3 support ?two? years back - it looks like the same issue. This problem is fixed in the gcc cvs trunk. I've asked Danny and Gerrit about backporting the fix to 3.3.2. It should be trivial to do so. In fact, the test case I created back then passes now. It may be a variant on a theme though. So, Chris, are there any parts you've seen so far, that you've be happy to ok (i.e. the MAX_PATH-CYG_MAX_PATH rename), or the global search and replaces to the thunk functions? I haven't looked at anything in great detail. This is not the best possible time for me to be reviewing massive changes to cygwin, unfortunately. Ah. Well while there are a lot of textual changes, there are only a few logical changes. I'm happy to throw this into a branch and let you ponder - but I only have a few hours to actually work on it. As far as applications maing assumptions, unix file systems don't guarantee PATH_MAX: thats an upper limit of the OS, applications are expected to be able to handle to up to PATH_MAX... but can't expect the OS to do so in every case. It is fairly unusual for PATH_MAX to be many times greater than what is support by pathconf. Now, for global use of an A or W function, Chris' utf patch which I just ran into digging into a INVALID_NAME error, also chose at runtime. I can easily alter IOThunkState to always use W if available, and then check a cached flag from then on in. I really think that the current overhead will be low enough to be a non-issue though. Sorry but you've lost me. I don't know what my utf patch is. Chris January :}. For the record, I don't have any problems with changing PATH_MAX to CYG_PATH_MAX as a first step for this change. Small steps are, as always, appreciated. Alrighty, will commit that in a minute. Rob
Re: For masochists: the leap o faith
Christopher Faylor wrote: On Sat, Nov 15, 2003 at 07:31:42AM +1100, Robert Collins wrote: Robert Collins wrote: Ok, so this it for tonight, my bed is calling me. As far as applications maing assumptions, unix file systems don't guarantee PATH_MAX: thats an upper limit of the OS, applications are expected to be able to handle to up to PATH_MAX... but can't expect the OS to do so in every case. It is fairly unusual for PATH_MAX to be many times greater than what is support by pathconf. And yet: http://www.opengroup.org/onlinepubs/007908799/xsh/fpathconf.html the notes allude to the issue: unless you call [f]pathconf with a path for details on, some implementations won't supply valid information. You're right though, that we need to update [f]pathconf as part of this. If the implementation needs to use path to determine the value of name and the implementation does not support the association of name with the file specified by path, or if the process did not have appropriate privileges to query the file specified by path, or path does not exist, pathconf() returns -1 and errno is set to indicate the error. and in http://www.opengroup.org/onlinepubs/007908799/xsh/limits.h.html we have Pathname Variable Values The values in the following list may be constants within an implementation or may vary from one pathname to another. For example, file systems or directories may have different characteristics. A definition of one of the values will be omitted from the limits.h header on specific implementations where the corresponding value is equal to or greater than the stated minimum, but where the value can vary depending on the file to which it is applied. The actual value supported for a specific pathname will be provided by the pathconf() function. I think we need to remove the PATH_MAX constant as per their comment, as we will now offer runtime differences: win9X NT FAT NT NTFS. NAME_MAX will still be constant, (although I haven't reviewed msdn on that yet). Rob
Re: For masochists: the leap o faith
Christopher Faylor wrote: For the record, I don't have any problems with changing PATH_MAX to CYG_PATH_MAX as a first step for this change. Small steps are, as always, appreciated. Ok, so thats done. What about, for a next step, simply the introduction of the thunk layer - with only A calls used by it. No Unicode, no length changes. ? Thats probably the most verbose change, with the least variety in approach. From there on in we can debate the relative merits of path_conv state versus IOThunkState and the like without a huge patch in the wings. Rob
Re: For masochists: the leap o faith
On Sat, Nov 15, 2003 at 09:48:46AM +1100, Robert Collins wrote: Christopher Faylor wrote: It is fairly unusual for PATH_MAX to be many times greater than what is support by pathconf. And yet: http://www.opengroup.org/onlinepubs/007908799/xsh/fpathconf.html Yes, I've already (obviously?) been to SUSv3. I wasn't talking about standards. I was talking about common practice. If you have a common practice web site that you want to show me then that might be a convincing argument. Otherwise, I'll have to fall back on my personal UNIX experience. I'm not vetoing the change because PATH_MAX is potentially large. I was kind of hoping (because I'm in incurable optimist) to start a discussion with people who were familiar with packages that used PATH_MAX. How SUSv3 defines PATH_MAX is irrelevant to existing programs. cgf
Re: For masochists: the leap o faith
On Sat, 2003-11-15 at 15:43, Christopher Faylor wrote: On Sat, Nov 15, 2003 at 09:48:46AM +1100, Robert Collins wrote: Christopher Faylor wrote: It is fairly unusual for PATH_MAX to be many times greater than what is support by pathconf. And yet: http://www.opengroup.org/onlinepubs/007908799/xsh/fpathconf.html Yes, I've already (obviously?) been to SUSv3. I wasn't talking about standards. I was talking about common practice. If you have a common practice web site that you want to show me then that might be a convincing argument. Otherwise, I'll have to fall back on my personal UNIX experience. I'm not vetoing the change because PATH_MAX is potentially large. I was kind of hoping (because I'm in incurable optimist) to start a discussion with people who were familiar with packages that used PATH_MAX. How SUSv3 defines PATH_MAX is irrelevant to existing programs. Well, it'll keep. I'll publish up my latest revision of the patch tonight, and leave it for Ron or other interested parties to carry through. There is obviously another couple of days work to get all the edges off, and then there's the gcc objects-on-stack issue to resolve. Still it'd be great to get this in, in some fashion. I would like to get the thunking changes in, simply to make the only part of the patch outstanding the controversial stuff. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
