Hi Tromey, Am Mittwoch, den 18.01.2006, 14:29 -0700 schrieb Tom Tromey: > >>>>> "Roman" == Roman Kennke <[EMAIL PROTECTED]> writes: > > Roman> Then we can use shorter macro names or even better function > Roman> calls like cp_mem_alloc() or something similar. > > Can we use the standard names, and then require the more bizarre > ports to do things like "#define malloc BlahBlah"?
That would most likely cause problems on these ports. The specific problem is that these ports actually have a malloc() syscall, only that it doesn't really do what you would expect, and the macro works around that by calling another (platform specific) syscall that does what's expected. The best thing I can offer is a shorter macro name. > The issue that came up here yesterday on irc is that, apparently, some > of these macros are only needed for ports that won't be in Classpath. I am aware of that problem. Still I don't know how to solve that problem. We simply cannot give away some of our ports, due to license and other restrictions. > Roman> - memcpy (_dst + dst_offset, src, dst_len); > Roman> + TARGET_NATIVE_MEMORY_FAST_COPY(src + index,_dst + > dst_offset,dst_len); > > There are still platforms without memcpy? What are they? > This seems like a great place for a target port to provide a > replacement function or macro. I can't quickly find a port that overrides this. Maybe this macro can be removed again. Let me investigate that. Roman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
