On Monday, August 29, 2011 04:42:04 Denys Vlasenko wrote:
> On Fri, 2011-08-26 at 15:56 -0400, Mike Frysinger wrote:
> > On Friday, August 26, 2011 13:32:17 Denys Vlasenko wrote:
> > > On Fri, 2011-08-26 at 20:36 +0400, Dmitry V. Levin wrote:
> > > > On Thu, Aug 25, 2011 at 12:10:06PM +0200, Denys Vlasenko wrote:
> > > > > +static struct i386_user_regs_struct i386_regs;
> > > > 
> > > > strace is not going to call PTRACE_GETREGS with different regs
> > > > structures, so is there any use to include the architecture name to
> > > > the structure name?
> > > 
> > > There *is* a reason to name it i386_regs: it makes it possible
> > > to easily find its uses.
> > > 
> > > For example,  Alpha, Blackfin and SH all have "static long r0". How can
> > > I quickly find only Alpha's usages of r0? There is no easy way to do
> > > it. I'd rather have them named alpha_r0, bfin_r0, sh_r0.
> > > 
> > > Same problem with variables named r10, a3 - several arches have them.
> > > "struct <something> regs" is used by FOUR architectures.
> > > 
> > > Variable pc is unique to S390, but it has such a short name that grep
> > > finds a lot of stray matches. Again, s390_pc would be much nicer.
> > 
> > i think this is a structure problem with the strace code base in general.
> > it'd be nice if we had all the arch-cruft in an arch-specific subdir
> > instead of sprinkling ifdefs everywhere.  changing the variable names is
> > a very poor- man's solution.
> 
> I am not proposing to change existing variables' names.
> I am explaining why I'm choosing names differently for NEW variables.

my point really wasnt relevant to the new/changing aspect, but to trying to 
namespace by prefixing variable names
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Strace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strace-devel

Reply via email to