This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java 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: Patch: jcf-path.c and filename case-insensitivity on Win32


Hi Andrew,

Thanks for your reply.

> > I'm going to stick my neck out here: would it be ethically/morally
> > objectionable to have platform-dependent files where we call into
> > platform-dependent same-named functions for things like these?
>
>In principle, but if we ever get into that much platform-dependent
>complexity in the compiler front end we are going it totally the wrong
>direction.

Why the distinction between the compiler front end and elsewhere in gcj?
Everywhere I look in the code, MingW seems like the proverbial black sheep,
causing trouble and stirring things up for the POSIX world. I agree with the
general principle that platform-specific code forks are undesirable, but
why would the compiler front end be more undesirable?

(A sidenote: the MingW build breaks at exactly the same place as this
attempted Mac OSX build: http://gcc.gnu.org/ml/java/2003-02/msg00325.html)

> > And if you're worried about performance on UNIX in the case of
> > something like strcmp,
>
>In the front end?  No way.  It must be right.

I didn't understand your last sentence. By "It must be right", do you
mean: "it must be implemented correctly/properly"?.

> > do a #define where things would resolve to the real deal on UNIX,
> > but a function call into the platform- dependent file on Win32?
> > 
> > I'm asking this because there are a few strategic opens / fopens
> > in jcf-*.c which, if you checked for the existence of the file
> > of the exact case on Win32, you would get the compiler working
> > on MingW.
>
>This should be possible to parameterize with a macro in the same way.
>Go for it.

I had thought about this too, but then I asked myself a general question:
how much of this macro stuff do we want to get into? The only advantage
I can see of a macro is to spare the overhead of another level of
indirection (another function call). Is the performance hit of such
indirection relevant on today's computers, given the increased readability
and debuggability? (Haven't mentally profiled this particular code enough
to be able to answer this.) And even though I may be able to get away with
a macro this time, what about the next time? And the next time? (Or won't
there be any next times? ;) )

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/





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