From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.schemamania.org (rrcs-50-75-19-234.nys.biz.rr.com [50.75.19.234]) by sourceware.org (Postfix) with ESMTP id F0175385840C for ; Sat, 19 Mar 2022 17:10:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F0175385840C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=schemamania.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=schemamania.org Received: from oak.schemamania.org (localhost [IPv6:::1]) by mail.schemamania.org (Postfix) with ESMTP id 64FF4256FADC for ; Sat, 19 Mar 2022 13:10:29 -0400 (EDT) Date: Sat, 19 Mar 2022 13:10:29 -0400 From: "James K. Lowden" To: gcc@gcc.gnu.org Subject: Re: passing command-line arguments, still Message-Id: <20220319131029.49490fb71bf0bbaae4c598bf@schemamania.org> In-Reply-To: References: <20220316143409.24cb3e7fd17c6b73acaee586@schemamania.org> <20220317122136.d15c4fd4f6ea9fec2cbc0938@schemamania.org> Reply-To: gcc@gcc.gnu.org X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RDNS_DYNAMIC, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2022 17:10:33 -0000 I'm collecting my remarks in one reply here, hopefully for easier reading. I want to offer my thanks, and also my assessment of the situation as I understand it. My critique is intended as purely constructive. I understand vaguely what's going on. I'll use the -findicator-column= form because it works, and because that's today's convention. I assert: 1. I did define my option to take an argument. 2. The documentation is incomplete and incorrect. 3. The naming convention is inconsistent. Joseph Myers answered my question directly: > The .opt files control how options are parsed, both in the driver and > in the compiler programs such as cc1. Passing of options from the > driver to those compiler programs is based on specs in the driver; -f > options are passed down because of the use of %{f*} in cc1_options > (and the use of %(cc1_options) in the specs for most languages). IIUC, it's not lang.opt, but lang-specs.h: $ nl lang-specs.h 1 /* gcc-src/gcc/config/lang-specs.h */ 2 {".cob", "@cobol", 0, 1, 0}, 3 {".COB", "@cobol", 0, 1, 0}, 4 {".cbl", "@cobol", 0, 1, 0}, 5 {".CBL", "@cobol", 0, 1, 0}, 6 {"@cobol", "cobol1 %i %(cc1_options) %{!fsyntax-only:% (invoke_as)}", 0, 1, 0}, The contents of that file are unspecified. gccint.info says only: > 'lang-specs.h' > This file provides entries for 'default_compilers' in 'gcc.c' > which override the default of giving an error that a compiler for that > language is not installed. I implemented the above by cargo-cult coding. Until today I had no idea what line 6 does. Now I have only some idea. I don't understand where the %{} syntax is processed. I'm guessing autoconf, which on this project is above my pay grade. On Thu, 17 Mar 2022 17:39:00 +0000 Jonathan Wakely wrote: > You didn't define your option to take an argument in the > .opt file. Of course I did: indicator-column Cobol Joined Separate UInteger Var(indicator_column) Init(0) IntegerRange(0, 8) Column after which Region B begins That says it takes an argument -- either Joined or Separate -- as an unsigned integer initialized to 0 in the range [0,8]. Not only that, the option is accepted by gcobol; it's just not passed to the compiler. The documentation does not say an option taking an argument must end in "=" and does not recommend it begin with "f". Marek Polacek wrote: > > 2. GCC accepts a -fno- alternative, automatically > > Right, unless it's RejectNegative. Yes, and RejectNegative is an instrument of accidental complexity. If -f options automatically accept a -fno- option, then a -f option that does not want a -fno- alternative should use another name. There are 25 other lowercase letters available. > > 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. IME, someone made a mistake in the past, and that mistake is now becoming mistaken for a standard. I don't mind living with some cruft -- it's not as though gcc is unique in that regard -- but at the same time I see no reason to vernerate it or perpetuate it. In plain words, if we recognize that -f indicates an on/off switch, let's use it that way, deprecate those that don't, and not add new -f options that take arguments. One last, final minor point, > > By default, all options beginning with "f", "W" or "m" are > > implicitly assumed to take a "no-" form. > > More accurate would be > > to say a "fno-" form is automatically accepted or generated. > > TBH, I don't see how that would be any more accurate that what we > have now. Words matter. No one is assuming anything, a fact hidden by the passive "are implicitly assumed". I don't know whether -fno- is "accepted" or "generated", or by what. I'm suggesting the agent be stated and the verb not hide what's happening. I would say: "Options beginning with "f", "W" or "m" also a "no-" form generated by . I wouldn't say "by default", because it's not by default. It's by design, and the alternative is contained in the next sentence. I've said my peace. I have my option, and I'll use it. If any of my assertions is incorrect, I'd be happy to be corrected. I hope my observations, if correct, contribute to better option names and documentation. My thanks for your help. I'm sure we've spent more time on this corner of configuration than we expected to. --jkl