Re: passing command-line arguments, still

[Marek Polacek <polacek@redhat.com>]

On Thu, Mar 17, 2022 at 12:21:36PM -0400, James K. Lowden wrote:
> On Wed, 16 Mar 2022 14:45:33 -0400
> Marek Polacek <polacek@redhat.com> wrote:
> 
> Hi Marek, 
> 
> > Let's avoid -f-foo; use -ffoo instead, like the rest of GCC.
> 
> Sure. I hadn't noticed the distinction. 
> 
> > > In cobol/lang.opt, I have:
> > > 
> > > indicator-column
> > 
> > Make this 'findicator-column='.  Does that help?
> 
> Yes, with that change, the option & argument are passed.  But ... why?

I think Jon and Joseph answered your questions now.
 
> It's my understanding that the -f prefix indicates a switch, meaning:  
> 
> 1.  It does not take an argument

It may, as Jon showed.

> 2.  GCC accepts a  -fno- alternative, automatically

Right, unless it's RejectNegative.

> 3.  The "f" stands for "flag", meaning on/off.  

It does stand for "flag", and it looks like at some point in ancient
history if was on/off, but then came options like -falign-loops=N.
 
> My option has no alternative, if you'll pardon the pun.  I don't see
> the point in confusing the user by suggesting it does.  
> 
> The fine manual says:
> 
>      By default, all options beginning with "f", "W" or "m" are
>      implicitly assumed to take a "no-" form.  This form should not be
>      listed separately.  If an option beginning with one of these
>      letters does not have a "no-" form, you can use the
>      'RejectNegative' property to reject it.
> 
> That isn't quite accurate.  The "no-" form isn't "implicitly assumed".
> What would "explicitly assumed" look like, btw?  

I guess that you'd have two separate entries in whatever.opt:

ffoo
...

fno-foo
...

> More accurate would be
> to say a "fno-" form is automatically accepted or generated. Computer
> code does not make assumptions; programmers do.  

TBH, I don't see how that would be any more accurate that what we have now.


Anyway, did you figure it out or are there some lingering questions?

Marek