From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14641 invoked by alias); 18 Dec 2001 19:28:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14469 invoked from network); 18 Dec 2001 19:27:00 -0000 Received: from unknown (HELO hugin.diku.dk) (130.225.96.144) by sources.redhat.com with SMTP; 18 Dec 2001 19:27:00 -0000 Received: (qmail 20016 invoked from network); 18 Dec 2001 19:26:58 -0000 Received: from tyr.diku.dk (terra@130.225.96.226) by hugin.diku.dk with QMQP; 18 Dec 2001 19:26:58 -0000 Date: Tue, 18 Dec 2001 11:41:00 -0000 Message-ID: <20011218192658.16865.qmail@tyr.diku.dk> From: Morten Welinder To: gcc@gcc.gnu.org cc: torvalds@transmeta.com Subject: Re: Big-endian Gcc on Intel IA32 X-SW-Source: 2001-12/txt/msg00999.txt.bz2 Linus Torvalds wrote... > (Inside the kernel, I'd love to be able to taint pointers and data that > came from user space, for example, to make sure that the compiler will > refuse to even _compile_ code that uses such data without the proper > safety checks. This is not all that different from keeping track of what > byte-order a specific datum has). I would guess that you can do this with C++. Now I realize that you are not about to rewrite the kernel in C++ (unless you have sampled a bit too much Glogg recently, :-) What I am saying is that you could probably make minor changes to the current source code such that... 1. Its C interpretation does not change. 2. Its C++ interpretation would have a user_data* type and do the check you ask for. I.e., you could use g++ as the San Jose checker, ;-) The .o files would not be any good, of course. I seem to remember that once upon a time you said that you wanted type int when you deal with ints (as opposed to having some typedef name like off_t). If that is still true, I guess you will not like this kind of approach. Morten