On Wed, 30 Aug 2023 23:15:13 +0100
Richard Harnden <richard.nospam@gmail.com> wrote:
> On 30/08/2023 21:07, Spiros Bousbouras wrote:
>
> >
> > I said
> > the wrapper function take as a single argument a pointer to struct
> >
>
> Can a struct have the same qualifiers as a function?
>
> I mean, say you have:
> void foo(const char * restrict bar);
>
> Can you have ...?
>
> struct foo
> {
> const char * restrict bar;
> };
>
> void foos(struct foo foo);
>
> ... ?
>
> Does the const/restrict'ness survive?

The syntax allows it but to what extent the semantics are different , I'm not
sure. For restrict I'm not clear about the details even if it's not a member
of a structure.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-08-31, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> in identifiers. As an example, consider an implementation that
>> supports the common extension of allowing dollar signs in
>> identifiers. It would make sense, in case a keyboard is being
>> used that doesn't have a dollar sign key, to allow the universal
>> character name for dollar sign (\u0024, IIANM). Other universal
>
> Maybe let that coder expense $15 on the company credit card to get a
> better keyboard instad of inflicting \u0024 on future maintainers of the
> code.

A pointless observation. It's the implementor who is making
the decision, and it's easier just to put in the exception
than to try to convince even one potential user to get a new
keyboard.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-08-31, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>
>>> On Tue, 29 Aug 2023 19:22:09 +0000, Kaz Kylheku wrote:
>>>
>>>> On 2023-08-29, David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>>> On 29/08/2023 01:07, Tim Rentsch wrote:
>>>>>
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>
>>>>>>> I will use [underscore] in preference to CamelCase, which I
>>>>>>> dislike primarily because of the impact on my typing speed.
>>>>>>
>>>>>> In most cases I find CamelCase harder to read than using
>>>>>> underscores, especially when using mono-spaced fonts.
>>>>>
>>>>> I used to use camelCase for most of my identifiers - now I find I
>>>>> am using underscores much more, precisely because I find it easier
>>>>> to read. I strongly suspect it is age-related - camelCase was
>>>>> more appealing when my eyes were younger.
>>>>
>>>> CamelCase is at odds with the C language.
>>>
>>> I would disagree. CamelCase (as in identifiers consisting of a mix of
>>> upper and lower case characters) is inherent in the definition of an
>>> identifier, and has been since K&R C. [...]
>>
>> CamelCase is consistent with C syntax; it feels out of place
>> though in terms of common usage.

>> ISTM that CamelCase was never
>> used in C until C++ started using it, which I think started
>> happening because Smalltalk uses camelCase (and CamelCase), and
>> C++ has Smalltalk envy.

[various bits of esoterica about C++ and CamelCase]

The key point is that CamelCase tends to be relatively common
in C++, and not nearly as common in C. All the C++ esoterica
is just noise.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Being able to accept $ in identifiers is a convenient extension.
>
> Quibble: $ in identifiers is not an extension as specified in section 4
> of the standard. Starting in C99, the set of characters accepted in
> identifiers is implementation-defined. (I'm not sure what difference
> that makes.)

On further thought, there is a significant difference.

An implementation that supports $ in identifiers via an via the
"other implementation-defined characters" wording in the syntax
of an identifier can accept foo$bar as an identifier without
issuing a diagnostic. If it's an extension as defined in section 4
(Conformance) of the standard, it can accept foo$bar but it must
still issue a diagnostic (presumably a non-fatal warning).

(That's in conforming mode, of course. The standard has nothing to say
about non-conforming modes.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>
>>> Being able to accept $ in identifiers is a convenient extension.
>>
>> Quibble: $ in identifiers is not an extension as specified in section 4
>> of the standard. Starting in C99, the set of characters accepted in
>> identifiers is implementation-defined. (I'm not sure what difference
>> that makes.)
>
> On further thought, there is a significant difference.
>
> An implementation that supports $ in identifiers via an via the
> "other implementation-defined characters" wording in the syntax
> of an identifier can accept foo$bar as an identifier without
> issuing a diagnostic. If it's an extension as defined in section 4
> (Conformance) of the standard, it can accept foo$bar but it must
> still issue a diagnostic (presumably a non-fatal warning).

I'm not sure that's right. Section 5.1.1.3 paragraph 1 says

A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as
undefined or implementation-defined.

Note the last clause: "even if the behavior is also explicitly
specified as undefined or implementation-defined." This clause
suggests that accepting $ as one of the implementation-defined
characters still warrants a diagnostic.

(And as was pointed out, only if the compiler is invoked in what
is purported to be a conforming mode.)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> Being able to accept $ in identifiers is a convenient extension.
>>>
>>> Quibble: $ in identifiers is not an extension as specified in section 4
>>> of the standard. Starting in C99, the set of characters accepted in
>>> identifiers is implementation-defined. (I'm not sure what difference
>>> that makes.)
>>
>> On further thought, there is a significant difference.
>>
>> An implementation that supports $ in identifiers via an via the
>> "other implementation-defined characters" wording in the syntax
>> of an identifier can accept foo$bar as an identifier without
>> issuing a diagnostic. If it's an extension as defined in section 4
>> (Conformance) of the standard, it can accept foo$bar but it must
>> still issue a diagnostic (presumably a non-fatal warning).
>
> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
>
> A conforming implementation shall produce at least one
> diagnostic message (identified in an implementation-defined
> manner) if a preprocessing translation unit or translation
> unit contains a violation of any syntax rule or constraint,
> even if the behavior is also explicitly specified as
> undefined or implementation-defined.
>
> Note the last clause: "even if the behavior is also explicitly
> specified as undefined or implementation-defined." This clause
> suggests that accepting $ as one of the implementation-defined
> characters still warrants a diagnostic.

Ah, but the "implementation-defined characters" are part of the syntax.

As of C11, the grammar for an identifier is:

identifier:
identifier-nondigit
identifier identifier-nondigit
identifier digit
identifier-nondigit:
nondigit
universal-character-name
other implementation-defined characters
nondigit: one of
[_, a..z, A..Z]
digit: one of
[0..9]

If $ is one of the "other implementation-defined characters" for a given
implementation, then `foo$bar` does not violate a syntax rule.

> (And as was pointed out, only if the compiler is invoked in what
> is purported to be a conforming mode.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>> [...]
>>>>
>>>>> Being able to accept $ in identifiers is a convenient extension.
>>>>
>>>> Quibble: $ in identifiers is not an extension as specified in section 4
>>>> of the standard. Starting in C99, the set of characters accepted in
>>>> identifiers is implementation-defined. (I'm not sure what difference
>>>> that makes.)
>>>
>>> On further thought, there is a significant difference.
>>>
>>> An implementation that supports $ in identifiers via an via the
>>> "other implementation-defined characters" wording in the syntax
>>> of an identifier can accept foo$bar as an identifier without
>>> issuing a diagnostic. If it's an extension as defined in section 4
>>> (Conformance) of the standard, it can accept foo$bar but it must
>>> still issue a diagnostic (presumably a non-fatal warning).
>>
>> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
>>
>> A conforming implementation shall produce at least one
>> diagnostic message (identified in an implementation-defined
>> manner) if a preprocessing translation unit or translation
>> unit contains a violation of any syntax rule or constraint,
>> even if the behavior is also explicitly specified as
>> undefined or implementation-defined.
>>
>> Note the last clause: "even if the behavior is also explicitly
>> specified as undefined or implementation-defined." This clause
>> suggests that accepting $ as one of the implementation-defined
>> characters still warrants a diagnostic.
>
> Ah, but the "implementation-defined characters" are part of the
> syntax. [...]

I know that. Since the sentence in 5.1.1.3 p1 specifically calls
out cases that are explicitly implementation-defined, it should
take precedence. There is a violation of a syntax rule; any
argument that there isn't has to rely on implementation-defined
behavior, and thus a diagnostic is required.

On 9/3/23 4:47 PM, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> [...]
>>>>>
>>>>>> Being able to accept $ in identifiers is a convenient extension.
>>>>>
>>>>> Quibble: $ in identifiers is not an extension as specified in section 4
>>>>> of the standard. Starting in C99, the set of characters accepted in
>>>>> identifiers is implementation-defined. (I'm not sure what difference
>>>>> that makes.)
>>>>
>>>> On further thought, there is a significant difference.
>>>>
>>>> An implementation that supports $ in identifiers via an via the
>>>> "other implementation-defined characters" wording in the syntax
>>>> of an identifier can accept foo$bar as an identifier without
>>>> issuing a diagnostic. If it's an extension as defined in section 4
>>>> (Conformance) of the standard, it can accept foo$bar but it must
>>>> still issue a diagnostic (presumably a non-fatal warning).
>>>
>>> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
>>>
>>> A conforming implementation shall produce at least one
>>> diagnostic message (identified in an implementation-defined
>>> manner) if a preprocessing translation unit or translation
>>> unit contains a violation of any syntax rule or constraint,
>>> even if the behavior is also explicitly specified as
>>> undefined or implementation-defined.
>>>
>>> Note the last clause: "even if the behavior is also explicitly
>>> specified as undefined or implementation-defined." This clause
>>> suggests that accepting $ as one of the implementation-defined
>>> characters still warrants a diagnostic.
>>
>> Ah, but the "implementation-defined characters" are part of the
>> syntax. [...]
>
> I know that. Since the sentence in 5.1.1.3 p1 specifically calls
> out cases that are explicitly implementation-defined, it should
> take precedence. There is a violation of a syntax rule; any
> argument that there isn't has to rely on implementation-defined
> behavior, and thus a diagnostic is required.

No, it says that *IF* there is a violation of a syntax rule, there must
be a diagnostic, even if the results of that violation is indicated to
be undefined or implementation defined.

If $ is an implmenetation defined identifier character, then no
violation of a syntax rules exist.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> [...]
>>>>>> Being able to accept $ in identifiers is a convenient extension.
>>>>>
>>>>> Quibble: $ in identifiers is not an extension as specified in section 4
>>>>> of the standard. Starting in C99, the set of characters accepted in
>>>>> identifiers is implementation-defined. (I'm not sure what difference
>>>>> that makes.)
>>>>
>>>> On further thought, there is a significant difference.
>>>>
>>>> An implementation that supports $ in identifiers via an via the
>>>> "other implementation-defined characters" wording in the syntax
>>>> of an identifier can accept foo$bar as an identifier without
>>>> issuing a diagnostic. If it's an extension as defined in section 4
>>>> (Conformance) of the standard, it can accept foo$bar but it must
>>>> still issue a diagnostic (presumably a non-fatal warning).
>>>
>>> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
>>>
>>> A conforming implementation shall produce at least one
>>> diagnostic message (identified in an implementation-defined
>>> manner) if a preprocessing translation unit or translation
>>> unit contains a violation of any syntax rule or constraint,
>>> even if the behavior is also explicitly specified as
>>> undefined or implementation-defined.
>>>
>>> Note the last clause: "even if the behavior is also explicitly
>>> specified as undefined or implementation-defined." This clause
>>> suggests that accepting $ as one of the implementation-defined
>>> characters still warrants a diagnostic.
>>
>> Ah, but the "implementation-defined characters" are part of the
>> syntax. [...]
>
> I know that. Since the sentence in 5.1.1.3 p1 specifically calls
> out cases that are explicitly implementation-defined, it should
> take precedence. There is a violation of a syntax rule; any
> argument that there isn't has to rely on implementation-defined
> behavior, and thus a diagnostic is required.

I disagree. A diagnostic is required if:
- A syntax rule or constraint is violated; or
- A syntax rule or constraint is violated and the behavior is explicitly
undefined; or
- A syntax rule or constraint is violated and the behavior is
explicitly implementation-defined.

(The last two cases are arguably covered by the first.)

In this case, no syntax rule is violated, so none of the cases apply,
so no diagnostic is required.

The syntax rule is not violated because the implementation-defined
character is part of the syntax rule. (See the parent article where I
quoted the syntax rule, or see the standard.) It's not the *behavior*
that's implementation defined, it's the *syntax rule*.

I do find it a bit odd, and potentially inconvenient, that one
implementation can quietly accept foo$bar as an identifier and another
can reject it as a syntax error, but that's what the standard says.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 8/30/23 14:44, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
....
>> The defining characteristic of a C extension is "A conforming
>> implementation may have extensions (including additional library
>> functions), provided they do not alter the behavior of any strictly
>> conforming program." Since it is implementation-defined whether those
>> characters can be used, a strictly conforming program cannot use them,
>>
>> I would have preferred that they call these "conforming" extensions -
>> that is, extensions that do not render the implementation
>> non-conforming. I think it would be appropriate to talk about extensions
>> that render an implementation non-conforming, calling them
>> "non-conforming extensions".
>
> That might be useful, but I suggest that anything that renders an
> implementation non-conforming is simply outside the scope of the
> standard.

Sorry for the late reply. I've been in quarantine due to Covid-19, and
my computer was not in quarantine with me.

A very large fraction of all of the things I would be inclined to call
"extensions" to C do in fact render the implementation that supports
them non-conforming. That doesn't have to be the case - if it gives a
meaning to keywords that aren't standard C keywords, all it would have
to do is give those keywords names that are reserved to the
implementation. Any use of those keywords could trigger a single
diagnostic message "Congratulations for using our [description]
extension". But not all implementors bother doing that.

I therefore find it annoying that C's definition of extensions cannot be
used to refer to such things.

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/3/23 4:47 PM, Tim Rentsch wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> [...]
>>>>>>
>>>>>>> Being able to accept $ in identifiers is a convenient extension.
>>>>>>
>>>>>> Quibble: $ in identifiers is not an extension as specified in section 4
>>>>>> of the standard. Starting in C99, the set of characters accepted in
>>>>>> identifiers is implementation-defined. (I'm not sure what difference
>>>>>> that makes.)
>>>>>
>>>>> On further thought, there is a significant difference.
>>>>>
>>>>> An implementation that supports $ in identifiers via an via the
>>>>> "other implementation-defined characters" wording in the syntax
>>>>> of an identifier can accept foo$bar as an identifier without
>>>>> issuing a diagnostic. If it's an extension as defined in section 4
>>>>> (Conformance) of the standard, it can accept foo$bar but it must
>>>>> still issue a diagnostic (presumably a non-fatal warning).
>>>>
>>>> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
>>>>
>>>> A conforming implementation shall produce at least one
>>>> diagnostic message (identified in an implementation-defined
>>>> manner) if a preprocessing translation unit or translation
>>>> unit contains a violation of any syntax rule or constraint,
>>>> even if the behavior is also explicitly specified as
>>>> undefined or implementation-defined.
>>>>
>>>> Note the last clause: "even if the behavior is also explicitly
>>>> specified as undefined or implementation-defined." This clause
>>>> suggests that accepting $ as one of the implementation-defined
>>>> characters still warrants a diagnostic.
>>>
>>> Ah, but the "implementation-defined characters" are part of the
>>> syntax. [...]
>>
>> I know that. Since the sentence in 5.1.1.3 p1 specifically calls
>> out cases that are explicitly implementation-defined, it should
>> take precedence. There is a violation of a syntax rule; any
>> argument that there isn't has to rely on implementation-defined
>> behavior, and thus a diagnostic is required.
>
> No, it says that *IF* there is a violation of a syntax rule, there
> must be a diagnostic, even if the results of that violation is
> indicated to be undefined or implementation defined.
>
> If $ is an implmenetation defined identifier character, then no
> violation of a syntax rules exist.

I think there is more to be said in this discussion but I
have decided not to pursue it for now.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> [...]
>>>>>>
>>>>>>> Being able to accept $ in identifiers is a convenient extension.
>>>>>>
>>>>>> Quibble: $ in identifiers is not an extension as specified in section 4
>>>>>> of the standard. Starting in C99, the set of characters accepted in
>>>>>> identifiers is implementation-defined. (I'm not sure what difference
>>>>>> that makes.)
>>>>>
>>>>> On further thought, there is a significant difference.
>>>>>
>>>>> An implementation that supports $ in identifiers via an via the
>>>>> "other implementation-defined characters" wording in the syntax
>>>>> of an identifier can accept foo$bar as an identifier without
>>>>> issuing a diagnostic. If it's an extension as defined in section 4
>>>>> (Conformance) of the standard, it can accept foo$bar but it must
>>>>> still issue a diagnostic (presumably a non-fatal warning).
>>>>
>>>> I'm not sure that's right. Section 5.1.1.3 paragraph 1 says
>>>>
>>>> A conforming implementation shall produce at least one
>>>> diagnostic message (identified in an implementation-defined
>>>> manner) if a preprocessing translation unit or translation
>>>> unit contains a violation of any syntax rule or constraint,
>>>> even if the behavior is also explicitly specified as
>>>> undefined or implementation-defined.
>>>>
>>>> Note the last clause: "even if the behavior is also explicitly
>>>> specified as undefined or implementation-defined." This clause
>>>> suggests that accepting $ as one of the implementation-defined
>>>> characters still warrants a diagnostic.
>>>
>>> Ah, but the "implementation-defined characters" are part of the
>>> syntax. [...]
>>
>> I know that. Since the sentence in 5.1.1.3 p1 specifically calls
>> out cases that are explicitly implementation-defined, it should
>> take precedence. There is a violation of a syntax rule; any
>> argument that there isn't has to rely on implementation-defined
>> behavior, and thus a diagnostic is required.
>
> I disagree. A diagnostic is required if:
> - A syntax rule or constraint is violated; or
> - A syntax rule or constraint is violated and the behavior is explicitly
> undefined; or
> - A syntax rule or constraint is violated and the behavior is
> explicitly implementation-defined.
>
> (The last two cases are arguably covered by the first.)
>
> In this case, no syntax rule is violated, so none of the cases apply,
> so no diagnostic is required.
>
> The syntax rule is not violated because the implementation-defined
> character is part of the syntax rule. (See the parent article where I
> quoted the syntax rule, or see the standard.) It's not the *behavior*
> that's implementation defined, it's the *syntax rule*.
>
> I do find it a bit odd, and potentially inconvenient, that one
> implementation can quietly accept foo$bar as an identifier and another
> can reject it as a syntax error, but that's what the standard says.

I appreciate your comments and the thoughtfulness of the message.

I think there is more to be said in this discussion but I have
decided not to pursue it for now.