optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.

[Daniel Berlin]

The following reply was made to PR optimization/3329; it has been noted by GNATS.

From: Daniel Berlin <dan@dberlin.org>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
Cc: "'Richard Henderson'" <rth@redhat.com>,
   "'Andrew Pinski'"
	 <pinskia@physics.uc.edu>,
   "'rth@gcc.gnu.org'" <rth@gcc.gnu.org>,
   "'gcc-bugs@gcc.gnu.org'"
	 <gcc-bugs@gcc.gnu.org>,
   "'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
   "'nobody@gcc.gnu.org'"
	 <nobody@gcc.gnu.org>,
   "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: RE: optimization/3329: optimization large memory copies uses kern
	el memcpy function without user's knowledge.
Date: 02 Apr 2002 17:38:14 -0500

 On Tue, 2002-04-02 at 17:29, Araneda, Dorian wrote:
 > 
 > this may be the case, but I don't think 
 > a developer should know the kernel-hacking tricks 
 > to get their code to be portable across kernels.
 > 
 > x=y; 
 > is not intuitively interpreted as 
 > memcpy(&x,y,sizeof(x));
 > 
 According to the standard, it's perfectly normal.
 It says specifically that structure assignments may be implemented with
 memcpy. (footnote 38)
 In fact, it says that all assignments > 1 byte could be implemented by
 memcpy.
 
 > I can assure you that if gcc did a survey of all
 > the developers using gcc, the vast majority
 > would not have realized this was occurring
 > in their code.
 The vast majority wouldn't care, i'd wager.
 > 
 > if this is not the case and I am a twink when 
 > it comes to kernel development, gcc should still
 > be idiot proof.the compiler  should not make
 > assumptions that the user is ok with linking
 > unapproved kernel function calls.
 > 
 > is simple, I don't appreciate a compiler feature
 > that goes behind my back to include code I did not
 > ask for.
 But you did! We have done nothing the standard says we can't do.
 If you want to modify your compiler to not do this, feel free.
 After all, you have the source.
 
 > 
 > It is like someone who thinks they are being
 > polite by pushing someone in a wheelchair because
 > they feel that they need the help.
 > It is not good etiquette to do that when that
 > person neither asked for help or gave permission
 > to be pushed.
 >  
 > gcc may have had good intentions but is still
 > not right to override the user's intent in that
 > way.
 
 What intent?
 You keep making this assumption that what you think is right is what
 other people think is right.
 I would wager most users either don't care, or don't have a problem with
 it.
 
 > 
 > I do not see why it is so hard to understand
 > what I am trying to explain.  It is not about
 > what method is better.  It's about common courtesy
 > to the user.
 No it's not.
 It's about you being annoyed that we emit memcpy, and trying to come up
 with reasons why we shouldn't do it.
 None of which are persuasive, at least to me.
 
 > 
 > -Dorian
 > 
 > -----Original Message-----
 > From: Richard Henderson [mailto:rth@redhat.com]
 > Sent: Tuesday, April 02, 2002 5:02 PM
 > To: Araneda, Dorian
 > Cc: 'Andrew Pinski'; 'rth@gcc.gnu.org'; 'gcc-bugs@gcc.gnu.org';
 > 'gcc-prs@gcc.gnu.org'; 'nobody@gcc.gnu.org'; 'gcc-gnats@gcc.gnu.org'
 > Subject: Re: optimization/3329: optimization large memory copies uses
 > kern el memcpy function without user's knowledge.
 > 
 > 
 > There are two markups that export symbols from the kernel:
 > 
 >  (1) EXPORT_SYMBOL
 > 
 > 	This is used for symbols with which there are no
 > 	restrictions for use.
 > 
 >  (2) EXPORT_SYMBOL_GPL
 > 
 > 	This is used for symbols that may only be used with
 > 	modules that carry a GPL compatible license.
 > 
 > See linux/Documentation/DocBook/kernel-hacking.tmpl or
 > some post-processing thereof.
 > 
 > You will find that memcpy and all of the other gcc support
 > routines are exported with EXPORT_SYMBOL, and thus do not
 > contaminate your code.
 > 
 > 
 > r~