Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Sat, 31 Aug 2024 02:11:36 -0700
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <86msktukdz.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <vah4hr$2b9i8$5@dont-email.me> <vahngt$2dtm9$1@dont-email.me> <87r0abzcsj.fsf@bsb.me.uk> <vai1ec$2fns2$1@dont-email.me> <874j75zftu.fsf@bsb.me.uk> <valrj7$367a8$2@dont-email.me> <87mskwy9t1.fsf@bsb.me.uk> <vanq4h$3iieb$1@dont-email.me> <875xrkxlgo.fsf@bsb.me.uk> <vapitn$3u1ub$1@dont-email.me> <87o75bwlp8.fsf@bsb.me.uk> <vaps06$3vg8l$1@dont-email.me> <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk> <vaqefq$2arg$2@dont-email.me> <87h6b3uejz.fsf@bsb.me.uk> <87bk1buduc.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 31 Aug 2024 11:11:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3cdd2c972935d84ac5d0fafd9719092c";
	logging-data="1026164"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18RiqPVvmPlhmQnd+Jfr4O8c7ZPJhZyWx4="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:2ROmeIX4vdgi8bGuHVPrMIvqXUQ=
	sha1:ksxXjiuaLtDlLopxuB6YJ/j+MlQ=
Bytes: 5017

Ben Bacarisse <ben@bsb.me.uk> writes:

> Ben Bacarisse <ben@bsb.me.uk> writes:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>> On 8/29/24 12:06, Ben Bacarisse wrote:
>>> ...
>>>
>>>> I can't see what it is you object to in what I wrote.  I don't
>>>> disagree with anything you are saying (the "correct result" being
>>>> to reject a program that has, syntactically, the wrong thing on
>>>> the left hand side).
>>>
>>> No - the only requirement is that a diagnostic be produced.  A
>>> fully conforming implementation of C is allowed to accept such
>>> code and then generate an executable;  if you choose to execute
>>> the executable, the behavior is undefined.
>>
>> Sorry, I used a term incorrectly.  To put it informally, you must
>> be told that "this is not C".  Not everything is C even if a C
>> compiler will accept FORTRAN code as an extension.
>
> Actually I don't think I did.  I said "reject" and a compiler that
> says "this is not C" and then generates a executable is rejecting
> the code as far as I am concerned.

I would like to express a personal reaction.

I think what you said about rejecting a program isn't exactly
wrong, but it is misleading, and also, I think, inadvisable.  A
good general principle is not to use words with private meanings
in a venue where there is a different public meaning as
understood by a significant majority of participants in the
venue.

The response from James Kuyper is off the mark in my view and so
enters the conversation at cross purposes.  The quotes around the
phrase "correct result" should be enough to make clear that you
are not making a precise statement about what the C standard
requires, but instead giving an informal description of a reaction
to a well-defined condition.  James is dragging the conversation
into a domain that is not quite the same as the one of your
comment.

That said, I still think "reject" is a poor word choice there,
whatever you might think of it privately, for two reasons.
Reason one, it goes against the common ordinary meaning of the
word.  Reason two, although the C standard does not use the word
"reject" at all, it does use the word "accept", and it is natural
to take "reject" to mean the opposite of "accept", but that sense
of "reject" is not what you mean (at least, I don't think it is).

Incidentally, the C standard doesn't say anything about refusing
an entire program.  What it does say is that implementations must
not successfully translate a preprocessing translation unit that
has an unskipped #error directive.  Presumably a not-successfully
translated preprocessing translation unit is meant to imply that
any program that tries to incorporate that translation unit must
also be invalid, but I don't think the C standard ever actually
says that.  (Disclaimer:  I haven't checked this claim carefully.)

On the question of what phrase to use instead, I might suggest
"must flag the program as being erroneous (in the sense that it
does not comply with the rules given in the C standard for what
constitutes a C source file)".  That's a long phrase, but I think
the first part - "must flag the program as being erroneous" -
expresses what it is you want to convey.  And I think it would be
understood by C-standard-experts in a way that's compatible with
what you want to say.

So, for what it's worth, there are my thoughts.