[ECOS] _impure_ptr ??
Jonathan Larmour
jifl@eCosCentric.com
Tue Mar 25 01:09:00 GMT 2003
Bart Veer wrote:
> However that was done before we had a common HAL package, CYGPKG_HAL.
> I think there is actually an argument for moving memcpy() and
> memmove() to the common HAL, leaving infra containing
> assert/trace/testing support. That reasoning would place
> __cxa_pure_virtual() in the common HAL as well.
Actually thinking about it, I would argue that we should just make
CYGPKG_LIBC_STRING compulsory. The package contains no weird and wacky
constraints, and as it is, people have written code in eCos that just
assumes these functions are present, without appropriate requires
statements in CDL (although I've done my best to try and do this).
The single overhead is build time, and even that's not much.
The big plus is being able to _drop_ any CDL that checks whether its there
or not. Simple string functions are virtually "infrastructure" in any
environment. It also adds many simplifications elsewhere - just look at
the testcases, plenty of which define their own versions of these
functions just to be on the safe side.
No-one is going to write their own function called strcpy() that does
something completely different, or if they do, it would just mask the one
from the library anyway.
But if people don't like the idea of CYGPKG_LIBC_STRING being compulsory
and therefore moving those functions back in there, they should continue
to live in infra since they _are_ infrastructure, and have nothing
whatsoever to do with hardware abstraction.
As for __cxa_pure_virtual(), again infra is right for the same reason.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss
mailing list