* better name for var_integer et.al.
@ 2004-09-15 18:05 Andrew Cagney
2004-09-15 18:19 ` Joel Brobecker
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2004-09-15 18:05 UTC (permalink / raw)
To: gdb
Hello,
GDB has the variable types:
/* Unsigned Integer. *VAR is an unsigned int. The user can type 0
to mean "unlimited", which is stored in *VAR as UINT_MAX. */
var_uinteger,
/* Like var_uinteger but signed. *VAR is an int. The user can type 0
to mean "unlimited", which is stored in *VAR as INT_MAX. */
var_integer,
/* ZeroableInteger. *VAR is an int. Like Unsigned Integer except
that zero really means zero. */
var_zinteger,
I think calling something "integer" or "unsigned integer" but then not
allowing the value zero is just plain weird.
Would anyone have better names for the first two?
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: better name for var_integer et.al.
2004-09-15 18:05 better name for var_integer et.al Andrew Cagney
@ 2004-09-15 18:19 ` Joel Brobecker
2004-09-15 20:35 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2004-09-15 18:19 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
> /* Unsigned Integer. *VAR is an unsigned int. The user can type 0
> to mean "unlimited", which is stored in *VAR as UINT_MAX. */
> var_uinteger,
Ada calls such numbers "Positive". var_positive might be a good name.
> /* Like var_uinteger but signed. *VAR is an int. The user can type 0
> to mean "unlimited", which is stored in *VAR as INT_MAX. */
> var_integer,
I can't see any use for this semantics, but maybe it's due to my limited
experience. I looked at the current code, and most if not all of them
where just misuses of this kind. Some of them are really booleans (so I
suspect var_zinteger would be better), or postive numbers (so
var_positive would be better).
I not useful, I would consider just removing it.
> /* ZeroableInteger. *VAR is an int. Like Unsigned Integer except
> that zero really means zero. */
> var_zinteger,
var_integer? (assuming we get rid of the non-zero signed integer)
--
Joel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: better name for var_integer et.al.
2004-09-15 18:19 ` Joel Brobecker
@ 2004-09-15 20:35 ` Andrew Cagney
2004-09-16 0:29 ` Joel Brobecker
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2004-09-15 20:35 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb
>>> /* Unsigned Integer. *VAR is an unsigned int. The user can type 0
>>> to mean "unlimited", which is stored in *VAR as UINT_MAX. */
>>> var_uinteger,
>
>
> Ada calls such numbers "Positive". var_positive might be a good name.
Or var_ordinal_number (vs cardinal number)?
>>> /* Like var_uinteger but signed. *VAR is an int. The user can type 0
>>> to mean "unlimited", which is stored in *VAR as INT_MAX. */
>>> var_integer,
Well, the "set backtrace limit 100" bug comes from a comparison between
signed (frame->limit == -1) vs unsigned (backtrace_limit == 100)
comparison which is from a var_uinteger.
Using var_integer "fixes" it but lets a user enter -100.
> I can't see any use for this semantics, but maybe it's due to my limited
> experience. I looked at the current code, and most if not all of them
> where just misuses of this kind. Some of them are really booleans (so I
> suspect var_zinteger would be better), or postive numbers (so
> var_positive would be better).
>
> I not useful, I would consider just removing it.
>
>
>>> /* ZeroableInteger. *VAR is an int. Like Unsigned Integer except
>>> that zero really means zero. */
>>> var_zinteger,
>
>
> var_integer? (assuming we get rid of the non-zero signed integer)
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: better name for var_integer et.al.
2004-09-15 20:35 ` Andrew Cagney
@ 2004-09-16 0:29 ` Joel Brobecker
0 siblings, 0 replies; 4+ messages in thread
From: Joel Brobecker @ 2004-09-16 0:29 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
> >Ada calls such numbers "Positive". var_positive might be a good name.
>
> Or var_ordinal_number (vs cardinal number)?
Yew! (sorry).
I prefer var_positive. Or var_nonzero_positive.
> >>> /* Like var_uinteger but signed. *VAR is an int. The user can type 0
> >>> to mean "unlimited", which is stored in *VAR as INT_MAX. */
> >>> var_integer,
>
> Well, the "set backtrace limit 100" bug comes from a comparison between
> signed (frame->limit == -1) vs unsigned (backtrace_limit == 100)
> comparison which is from a var_uinteger.
>
> Using var_integer "fixes" it but lets a user enter -100.
What would it mean, at the semantic level if the user entered
such a value? Shouldn't this value always be positive, with a
zero value being infinity?
Anyway, if we need to keep this kind of variables, how about
var_nonzero_integer (in line with one of the proposals above).
> >>> /* ZeroableInteger. *VAR is an int. Like Unsigned Integer except
> >>> that zero really means zero. */
> >>> var_zinteger,
> >
> >
> >var_integer? (assuming we get rid of the non-zero signed integer)
And then this one could become var_integer (an integer range contains
value zero by default, so no need to emphasize it with the 'z', IMHO).
--
Joel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-09-16 0:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-15 18:05 better name for var_integer et.al Andrew Cagney
2004-09-15 18:19 ` Joel Brobecker
2004-09-15 20:35 ` Andrew Cagney
2004-09-16 0:29 ` Joel Brobecker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).