This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: _impure_ptr ??
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