Dave Korn wrote:
On 10 November 2006 21:18, Brooks Moses wrote:
But that's already not possible -- that's essentially how I got into
this problem in the first place. If one tries to define both of those,
the declaration of the enumeration-type holding the option flags breaks,
so you can't do that.
That aside, it would have been possible before, and the mangling could
easily have been fixed to support it had we wanted to.
Right, yeah -- my point was just that nobody _had_ fixed the mangling to
support it, and thus that this was only eliminating a theoretical
possibility rather than something someone might actually be doing, which
means in practice it's not changing very much.
Are there any meaningful downsides to just having the option-matcher
treat all '-' and '=' values in the option name as equivalent? It would
mean that we'd also match "-ffixed=line=length-none", for instance, but
I don't think that causes any real harm.
I think it's horribly ugly! (Yes, this would not be a show-stopper in
practice; I have a more serious reason to object, read on...)
I think it's horribly ugly, too -- but I don't see that the ugliness
shows up anywhere unless some user is _intentionally_ doing something
ugly; it just means that their ugly usage is rewarded by the compiler
doing essentially what they expect, rather than throwing an error.
An alternative would be to specify that an '=' in the name in the .opt
file will match either '=' or '-' on the command line. This does
require that the canonical form be the one with '=' in it, and means
that things with '-' in them need to be changed in the .opt file to
accept both, but the benefit is that it can accept pseudo-Joined options
in either form without accepting all sorts of wierd things with random
'='s in them.
I think that for this one case we should just say that you have to supply
both forms -ffixed-line-length-none and -ffixed-line-length=none.
Which I would be glad to do, except that as far as I can tell, it's not
possible to actually do that. The same problem arises there as arises
when it doesn't have "none" on the end and "Joined" in the specification.
What you have here is really a joined option that has an argument that can
be either a text field or an integer, and to save the trouble of parsing the
field properly you're playing a trick on the options parser by specifying
something that looks to the options machinery like a longer option with a
common prefix, but looks to the human viewer like the same option with a text
rather than integer parameter joined.
Right, agreed. Though it's not so much "to save the trouble" as "to be
able to leverage all the useful things the option parser does to verify
numeric fields".
Treating a trailing '-' as also matching a '=' (and vice-versa) doesn't blur
the boundary between what are separate concepts in the option parsing
machinery. I think if you really want these pseudo-joined fields, add support
to the machinery to understand that the joined field can be either a string or
a numeric.
Well, I'm not sure that I "want" them, exactly. They're only in
gfortran because we're supporting backwards compatibity going back to
the very early days of g77.
The change I'm proposing is kind of orthogonal to that. It solves your
problem with the enum; there becomes only one enum to represent both forms and
both forms are accepted and parse to that same enumerated value. It does not
solve nor attempt to address your other problem, with the limitations on
parsing joined fields, and I don't think we should try and bend it into shape
to do this second job as well.
If you address the parsing limitation on joined fields, the flexibility that
my suggestion offers /will/ automatically be available to your usage.
Hmm. Valid points.
And, given that adding support for both string and numeric values looks
fairly easy (much more so than I would have guessed), that's probably
the better way to go. A UIntegerOrString property would be incompatible
with the Var property, since it would need two variables for storing the
result, but I think this is not a notable loss since the combination of
Var and UInteger is already rare -- the only flag that uses them both is
-fabi-version.
Or, given that the only thing that appears to use this at the moment is
this old g77-style fixed-line-length Fortran option that we're only
supporting for legacy purposes, I suppose we could just go for the
cop-out of supporting the "-none" version and not the "=none" version,
and only document it as accepting "=0".
- Brooks
