classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to


From: Torsten Rupp
Subject: Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to wrong address)
Date: Tue, 16 Nov 2004 10:46:10 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Dear Brian,

(and I thought
we agreed to get rid of these kind of macros and would use normal
functions as much as possible in the future.)

When I remember right, the agreement was not to remove the macros
completely, but instead make them into "alias"-names for target specific
implementations of some OS-function.


I believe Mark is correct here, we agreed to turn the macros into real
functions for debugging purposes.  And we'll probably use autoconf
feature testing for portability.  Getting to the alias-names of some
OS-function is a first step and then convert them into real functions.

When I understand the message from Michael from Aug-11-2004 right, we agreeded _not_ to remove the macro names completely (that would mean aicas will be kicked out from Classpath native code; I tried to explain this and why the macros are so important for aicas already in several messages), but instead make the following changes:

[part from the orignal message]

--- cut ---

> I have the following suggestion:
>
> Because the multiline-macros are to difficult to handle, we can
> replace that macros e. g. by direct function-calls. Thus a macro
> would become some "alias" only. We also can change (shorten) the
> names. For this we have to change the generic implementation. The
> advantages would be:
>
> - debugging is possible
> - type-safety
> - easier to read
>
> and for aicas
>
> - we can keep most of the code we already have written
> - we can continue to participate in Classpath
>
> For aicas this would be some compromise, because we can still use
> the target-layer. What would be still important is, that in the
> native _no_ OS-specific feature is used directly, like constants or
> datatypes or OS-functions calls. With such a implementation we can
> survive.

I like this idea. In fact I had the same in mind.

--- cut ---

Based on this idea I developed a POSIX-target layer. Unfortuantelly I'm currently to busy with my daily work, thus I still could not prepare the needed patches (which is also a difficult work). Soon I will have enough time I like to do this.

Sincerely,

Torsten





reply via email to

[Prev in Thread] Current Thread [Next in Thread]