This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: typedef fileline location_t

Carlo Wood wrote:

I think that correct naming is very important for
maintainability and would suggest to use a different
name for saved_lineno.  For example: saved_fileline.
You seem to use 'fileline' in new code for this,
sometimes just 'line' though.  Its confusing.

I couldn't find where you changed the meaning of
location_t though - if that is still a struct, then
the above 'input_location = 0' is really unreadable :/.

Now we have 'file' (ok), 'line' (huh?), 'fileline' (an int?)
'location' (?) and 'locus'.

That is one of the issues I wanted feedback on, but I wasn't explicit. The patches makes the two typedef names 'fileline' and 'location_t' equivalent. That is one too many. My suggestion is keeping 'fileline' and removing 'location_t' mainly because the work "location" is more ambiguous: It could just as easily refer to locations in memory or in a register, for example. A 'fileline' is less ambiguous.

We could replace the field name 'locus' for declarations
  fileline declared_at;

To answer your specific questions: a 'fileline' is a magic
(opaque) "cookie" whose implementation is an unsigned int.
I'd like to remove 'location' and 'location_t', but as a
follow-on cleanup patch.  'file' should be just the filename
as a char*, while 'line' is an actually line number (not a
fileline).  These are local variables.

The patches does use 'struct location_s' but only as a temporary
convenience menthod when you want to look at teh file or line
number.  It should probably be renamed to something like
'struct fileline_s' or 'struct fileline_struct'.
	--Per Bothner

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]