Re: [ECOS] _impure_ptr ??

[Jonathan Larmour <jifl at eCosCentric dot com>]

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