I was not talking about whether or not PATH_MAX was defined... I was referring to the ``<''. I cannot guarantee that such a condition would work on Cygwin because:
1) I have not seen it used before
2) I have not tried it myself
3) I have seen similar conditions that work find on other platforms but that do not work on Cygwin.
But, forget all of that.
What is important is that PATH_MAX is already defined by our system header, and the code in ast[...].h is not correctly detecting that PATH_MAX is already defined (could be a problem with the ordering of the includes). So, #if 0'ing the section of ast[...].h would give us more information and would most likely fix the build.
Harold
Benjamin Riefenstahl wrote:
Hi Harold,
Harold L Hunt II <[EMAIL PROTECTED]> writes:
#if defined(PATH_MAX) && (PATH_MAX < 255)I don't understand? If PATH_MAX is not defined it defaults to 0 in
# undef PATH_MAX
#endif
#ifndef PATH_MAX
# define PATH_MAX 255
#endif
Now, I cannot say that the (PATH_MAX < 255) conditional is actually
going to mean anything to the C preprocessor that we use, and I will
bet you money that this just breaks differently on other platforms
such that PATH_MAX is not being redefined (it is probably never
defined on those platforms).
preprocessor conditionals. That's just the definition of the C
language. This may break with a Classic C (pre-ISO C) preprocessor,
because basically *anything* can break on software that doesn't comply
with standards, but who really wants to support Classic C these days?
so long, benny
