From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13577 invoked by alias); 25 Mar 2003 00:56:26 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 13570 invoked from network); 25 Mar 2003 00:56:26 -0000 Received: from unknown (HELO jifvik.dyndns.org) (81.104.194.28) by sources.redhat.com with SMTP; 25 Mar 2003 00:56:26 -0000 Received: from eCosCentric.com (garibaldi.jifvik.org [172.31.1.2]) by jifvik.dyndns.org (Postfix) with ESMTP id 7016438885; Tue, 25 Mar 2003 00:56:25 +0000 (GMT) Message-ID: <3E7FA938.2020205@eCosCentric.com> Date: Tue, 25 Mar 2003 01:09:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.3) Gecko/20030314 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Bart Veer Cc: gary.thomas@mind.be, ecos-discuss@sources.redhat.com References: <1048336431.2225.5.camel@pc-002> <1048337300.4073.4345.camel@hermes.chez-thomas.org> <1048338100.2225.10.camel@pc-002> <1048340942.2225.24.camel@pc-002> <1048349264.24126.4.camel@pc-002> <20030324212605.F1897EC6F1@delenn.bartv.net> <1048541501.27601.1350.camel@hermes.chez-thomas.org> <20030324223600.D2679EC6F1@delenn.bartv.net> In-Reply-To: <20030324223600.D2679EC6F1@delenn.bartv.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ECOS] _impure_ptr ?? X-SW-Source: 2003-03/txt/msg00426.txt.bz2 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