This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 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]

Re: Building Eterm - please more help


Ben,

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 <huntharo@msu.edu> writes:

#if defined(PATH_MAX) && (PATH_MAX < 255)
# 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).

I don't understand? If PATH_MAX is not defined it defaults to 0 in
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








Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]