On 29/08/2023 22:12, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:

>> But rather than adding new ways to get inconsistent or undefined
>> behaviour, I would prefer taking the opportunity to make it harder to
>> get inconsistent or undefined behaviour here. We can't force people
>> to write good code, or to stop writing bad code - but we /can/
>> encourage it.
>
> Not if the additional changes intended to make the feature harder to
> abuse make it harder to use (and harder to explain).
>

Agreed. There are always balances and trade-offs involved. I do not
claim to know an "ideal" solution here (especially since "ideal" will
vary wildly for different people). But I think it should be an
important part of the discussion and consideration before implementing
such new features. In the end, I would expect to see the rules being
looser than I personally would prefer, and hope to see compilers provide
warnings or other flags to let people enforce tighter rules if they want.

On Wednesday, 30 August 2023 at 11:30:26 UTC+1, David Brown wrote:
> On 30/08/2023 09:43, Malcolm McLean wrote:
> > On Tuesday, 29 August 2023 at 21:00:14 UTC+1, David Brown wrote:
> >> On 29/08/2023 21:22, Kaz Kylheku wrote:
> >>> On 2023-08-29, David Brown <david...@hesbynett.no> wrote:
> >>>> On 29/08/2023 01:07, Tim Rentsch wrote:
> >>>>> sc...@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. It is not used in the standard
> >>> library, and it's not used in the related POSIX standard which comes
> >>> from the same birthplace.
> >>>
> >> Nonsense. Just because it is not used in the C standard library or
> >> POSIX does not make it "at odds with the C language". It might be more
> >> common in other languages than C, but it's fine for identifiers in C.
> >>
> > It's not in itself a knockdown, conclusive argument.
> > But it's a good argument. Match the standard library house style.
> It is not even remotely close to being a good argument.
>
> Consistency of style within a project, library, team, etc., is important
> and makes the code easier to write, easier to read, and easier to use.
> That's why projects or teams often have style guides.
>
> But there are no advantages in following a style from a different
> project. If you are contributing to the C standards, or an extended
> version of the C standard library, then follow the style for the C
> standard library - no word separators for short function names,
> underscores for long function names and macros, _t for types, etc. Most
> people, however, are /not/ writing code for the C standard library, and
> thus the style of the C standard library should not influence style for
> their own code.
>
You call the standard library in most C projects.
So the argument is that you should match the standard library style.
The alternative argument is that you should deliberately not match
the standard library style, to make it obvious which calls are standard
library calls and which are not.

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. The /language/ imposes no
restriction on the use of CamelCase (although, in "The C Programming
Language", K&R did note that "the underscore ... is useful for improving
the readability of long variable names").

> It is not used in the standard
> library, and it's not used in the related POSIX standard which comes
> from the same birthplace.

That may be more because of the compilation environment than because
of the language standards.

Remember, when the code that we now call the C standard library, and
the facilities that we now call the POSIX standard were initially
developed, the C language /implementations/ were limited by the
underlying host environment's restrictions on external names.

Some environments imposed a single case on external names (usually,
upper case only), so Strcmp() and strcmp(), while naming different
functions, would both resolve to the external name STRCMP. Kernighan,
Plauger, Ritchie, et al likely avoided mixed case external names
in the C and UNIX libraries for this reason alone.

> It's not used, or rarely used, in Unix file naming conventions,
> or for naming anything in the shell environment.

But, /not/ discouraged or forbidden.

> Makefile has an M just to put it ahead of lower-cased filenames
> in the lexicographic listing

Can you provide a definitive reference for that assertion?
I note that the 1978 Bell Labs version of make(1) read it's
dependency list from a file called "makefile"[1]. I do not
know when that changed to "Makefile".

> (which would not work if files had names
> like Parser.c and UserInterface.c.)

[snip]

[1] "Make - A Program for Maintaining Computer Programs"
S. I. Feldman, Bell Laboratories, August 15, 1978

--
Lew Pitcher
"In Skills We Trust"

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:
>>>>

>
>> Makefile has an M just to put it ahead of lower-cased filenames
>> in the lexicographic listing
>
>Can you provide a definitive reference for that assertion?
>I note that the 1978 Bell Labs version of make(1) read it's
>dependency list from a file called "makefile"[1]. I do not
>know when that changed to "Makefile".

Not sure about the assertion, but Unixware 2.1 make has:

static char makefile[] = "makefile",
Makefile[] = "Makefile",
Makeflags[] = "MAKEFLAGS",
RELEASE[] = "RELEASE";

And Unix v8:
$ strings /work/reference/usl/unix/v8/bin/make | grep Makefile
Makefile
s.Makefile

And Unix v7 tries 'makefile' first, if not found, then tries 'Makefile'.

if( !descset )
#ifdef unix
if( rddescf("makefile") ) rddescf("Makefile");
#endif
#ifdef gcos
rddescf("makefile");
#endif

On 30/08/2023 14:04, Malcolm McLean wrote:
> On Wednesday, 30 August 2023 at 11:30:26 UTC+1, David Brown wrote:
>> On 30/08/2023 09:43, Malcolm McLean wrote:
>>> On Tuesday, 29 August 2023 at 21:00:14 UTC+1, David Brown wrote:
>>>> On 29/08/2023 21:22, Kaz Kylheku wrote:
>>>>> On 2023-08-29, David Brown <david...@hesbynett.no> wrote:
>>>>>> On 29/08/2023 01:07, Tim Rentsch wrote:
>>>>>>> sc...@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. It is not used in the standard
>>>>> library, and it's not used in the related POSIX standard which comes
>>>>> from the same birthplace.
>>>>>
>>>> Nonsense. Just because it is not used in the C standard library or
>>>> POSIX does not make it "at odds with the C language". It might be more
>>>> common in other languages than C, but it's fine for identifiers in C.
>>>>
>>> It's not in itself a knockdown, conclusive argument.
>>> But it's a good argument. Match the standard library house style.
>> It is not even remotely close to being a good argument.
>>
>> Consistency of style within a project, library, team, etc., is important
>> and makes the code easier to write, easier to read, and easier to use.
>> That's why projects or teams often have style guides.
>>
>> But there are no advantages in following a style from a different
>> project. If you are contributing to the C standards, or an extended
>> version of the C standard library, then follow the style for the C
>> standard library - no word separators for short function names,
>> underscores for long function names and macros, _t for types, etc. Most
>> people, however, are /not/ writing code for the C standard library, and
>> thus the style of the C standard library should not influence style for
>> their own code.
>>
> You call the standard library in most C projects.

You do not /write/ the standard library for most C projects.

> So the argument is that you should match the standard library style.

The argument is worthless.

> The alternative argument is that you should deliberately not match
> the standard library style, to make it obvious which calls are standard
> library calls and which are not.
>

That is equally worthless as an argument.

On 8/30/23 06:44, David Brown wrote:
....
> Until it was mentioned in this thread, I didn't realise that dollars (or
> other characters) in identifiers were implementation-defined options,
> rather than requiring it to be an extension. (The distinction I would
> make here is that an "extension" is for something that the standard does
> not cover at all but is documented by the compiler - something that
> would be a syntax error, a constraint violation, or undefined behaviour
> if the compiler did not support it.)

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".

David Brown <david.brown@hesbynett.no> writes:
> On 29/08/2023 22:06, Keith Thompson wrote:
>> 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.)
>
> Until it was mentioned in this thread, I didn't realise that dollars
> (or other characters) in identifiers were implementation-defined
> options, rather than requiring it to be an extension. (The
> distinction I would make here is that an "extension" is for something
> that the standard does not cover at all but is documented by the
> compiler - something that would be a syntax error, a constraint
> violation, or undefined behaviour if the compiler did not support it.)
> As you say, I don't think there is a significant difference in
> practice, but I like to understand these things as accurately as I
> can, and I appreciate the bug-fix when I get them wrong.
>
> On a related note, I am looking at 6.4.2.1p3 (in C11) on "universal
> character names", and it appears to say that the characters must come
> from the list in D.1 (but not D.2, for the initial character), but
> also that implementations can allow other characters. This would make
> the D.1 list the minimal set allowed, but implementations could allow
> any (or almost any) other Unicode characters. Do you think that is
> right, or am I missing something?

C23 reworks the definition of "identifier". See N3096 6.4.2.1.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

An identifier may start with any of:
nondigit
XID_Start character
universal-character-name of class XID_Start
followed by zero or more of:
digit
nondigit
XID_Continue character
universal-character-name of class XID_Continue
where "digit" is one of 0..9 and "nondigit" is underscore or one of the
52 uppercase and lowercase Latin letters.

XID_Start and XID_Continue are specified in "UAX #44"
https://unicode.org/reports/tr44/
I haven't yet read enough of it to figure out what those mean.
Annex D has more information.

Under Semantics, N3096 says:
An XID_Start character is an implementation-defined character whose
corresponding code point in ISO/IEC 10646 has the XID_Start
property. An XID_Continue character is an implementation-defined
character whose corresponding code point in ISO/IEC 10646 has the
XID_Continue property.

My understanding is that an implementation will choose and document some
subset of the XID_Start and XID_Continue characters to be valid in
identifiers.

One odd thing (in both N1570 and N3096) is that the Semantics subsection
uses "shall". For example, N1570 6.4.2.1p3 says:

Each universal character name in an identifier shall designate a
character whose encoding in ISO/IEC 10646 falls into one of the
ranges specified in D.1. The initial character shall not be a
universal character name designating a character whose encoding
falls into one of the ranges specified in D.2.

This implies that a violation of such a requirement has undefined
behavior. I would have expected it to be a syntax error.

--
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 */

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 8/30/23 06:44, David Brown wrote:
> ...
>> Until it was mentioned in this thread, I didn't realise that dollars (or
>> other characters) in identifiers were implementation-defined options,
>> rather than requiring it to be an extension. (The distinction I would
>> make here is that an "extension" is for something that the standard does
>> not cover at all but is documented by the compiler - something that
>> would be a syntax error, a constraint violation, or undefined behaviour
>> if the compiler did not support it.)
>
> 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.

--
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 */

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tue, 29 Aug 2023 19:22:09 +0000, Kaz Kylheku wrote:
[...]
>> Makefile has an M just to put it ahead of lower-cased filenames
>> in the lexicographic listing
>
> Can you provide a definitive reference for that assertion?
> I note that the 1978 Bell Labs version of make(1) read it's
> dependency list from a file called "makefile"[1]. I do not
> know when that changed to "Makefile".

I wouldn't necessarily call this definitive, but the manual for GNU make
says:

Normally you should call your makefile either `makefile' or
`Makefile'. (We recommend `Makefile' because it appears prominently
near the beginning of a directory listing, right near other important
files such as `README'.) The first name checked, `GNUmakefile', is not
recommended for most makefiles. You should use this name if you have a
makefile that is specific to GNU `make', and will not be understood by
other versions of `make'. Other `make' programs look for `makefile' and
`Makefile', but not `GNUmakefile'.

That's from GNU make 3.75, released in 1996.

--
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 Mon, 28 Aug 2023 16:49:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> > Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >> I favor a different approach to this problem:
> >>
> >> static inline char *
> >> copy_to_from( char *to, const char *from ){
> >> return strcpy( to, from );
> >> }
> >>
> >> with no language changes needed. And people are still free to
> >> use the more concise form if they so desire.
> >
> > But if we change the names used in the standard for strcpy's parameters,
>
> Part of the point of my approach is that it doesn't need any
> changes to the C standard.
>
> > there's no need for a wrapper function (with, in your approach, a name
> > that doesn't suggest that it operates on strings).
>
> That's incidental. It could be copy_string_to_from();
>
> > Your wrapper would be useful only if the language added named arguments,
> > yes?
>
> Not at all, that's the point. The function name indicates where
> the destination (to) and source (from) arguments go. There is
> no reason a declaration has to use those names, or any names at
> all, for the function parameters. All the information needed
> is present in the name of the function.

If one is willing to write a wrapper function then why not do it like this :

struct struct_strcpy {
char * to ;
const char * from ;
}

and have the wrapper function take as a single argument a pointer to struct
struct_strcpy .This way no changes to the language are needed , everyone can
choose whatever member names they prefer , they can reuse the same structure
object if some members have the same value for different function calls (and
assign to the other members) and they can define a structure with default
values if they so wish.

Does having named arguments offer anything over this approach ?

> > I'd expect that an edition of the standard that added named
> > arguments would also rework the argument names in the standard library.
>
> Part of the advantage of the approach I favor is it doesn't
> need to wait for a new edition of the C standard. I think
> there are lots of cases where simply adopting a coding style
> obviates any need for new language features.

--
Every theatre is an insane asylum, but an opera theatre is the
ward for the incurables.
Franz Schalk

On 2023-08-30, David Brown <david.brown@hesbynett.no> wrote:
> On 30/08/2023 14:04, Malcolm McLean wrote:
>> You call the standard library in most C projects.
>
> You do not /write/ the standard library for most C projects.
>
>> So the argument is that you should match the standard library style.
>
> The argument is worthless.
>
>> The alternative argument is that you should deliberately not match
>> the standard library style, to make it obvious which calls are standard
>> library calls and which are not.
>
> That is equally worthless as an argument.

Coding conventions are arbitrarily chosen, an enforced not by arguments
but authority: ranging from "your patch is rejected" to "write like this
or find work somewhere else".

But there exists a consistency argument: if you don't conform to the
coding convention, then code becomes harder to work with. (As real
experience with mixed style codebases informs us.)

If the naming recommended by the coding convention is at odds with the
language, then that prevents maximal consistency from being reached.

If consistency is good, globally maximal consistency is better than
locally maximal consistency.

Thus there is exists a consistency argument against choosing
a CamelCase naming convention in a brand new C project with zero
legacy code.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
> If one is willing to write a wrapper function then why not do it like this :
>
> struct struct_strcpy {
> char * to ;
> const char * from ;
> }
>
> and have the wrapper function take as a single argument a pointer to struct
> struct_strcpy .This way no changes to the language are needed , everyone can
> choose whatever member names they prefer

Not according to the rule that struct types in different translation
units must havre the same member names if they are to be considered
compatible.

> they can reuse the same structure
> object if some members have the same value for different function calls (and
> assign to the other members) and they can define a structure with default
> values if they so wish.
>
> Does having named arguments offer anything over this approach ?

Pragmatics:

- Poor ergonomics of calling functions that take struct-encapsulated
tuple arguments instead of individual arguments.

- E.g. clumsy for a function to call another function that *almost* takes
the same arguments. The incoming struct must be destructured,
and the member values used to initialize the new structure.

- Reduced diagnosis: all arguments have become optional, because
designated initializers are optional! If we add a new parameter by
adding a member to the struct, the compiler will not find the places
that need a new argument.

- ABI concerns: binary compatibility now dominated by rules for
structure passing.

- Poor performance in ABIs that don't use registers for struct passing,
even for small structs.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Wed, 30 Aug 2023 19:53:02 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
> > If one is willing to write a wrapper function then why not do it like this :
> >
> > struct struct_strcpy {
> > char * to ;
> > const char * from ;
> > }
> >
> > and have the wrapper function take as a single argument a pointer to struct
> > struct_strcpy .This way no changes to the language are needed , everyone can
> > choose whatever member names they prefer
>
> Not according to the rule that struct types in different translation
> units must havre the same member names if they are to be considered
> compatible.

Why would anyone choose different member names in different translation
units ? They just declare the structure once in some header.

> > they can reuse the same structure
> > object if some members have the same value for different function calls (and
> > assign to the other members) and they can define a structure with default
> > values if they so wish.
> >
> > Does having named arguments offer anything over this approach ?
>
> Pragmatics:
>
> - Poor ergonomics of calling functions that take struct-encapsulated
> tuple arguments instead of individual arguments.
>
> - E.g. clumsy for a function to call another function that *almost* takes
> the same arguments. The incoming struct must be destructured,
> and the member values used to initialize the new structure.

I don't see how this becomes simpler with named arguments.

> - Reduced diagnosis: all arguments have become optional, because
> designated initializers are optional! If we add a new parameter by
> adding a member to the struct, the compiler will not find the places
> that need a new argument.

Yes this may be an issue. But compilers could warn about it.

> - ABI concerns: binary compatibility now dominated by rules for
> structure passing.
>
> - Poor performance in ABIs that don't use registers for struct passing,
> even for small structs.

I said
the wrapper function take as a single argument a pointer to struct

--
vlaho.ninja/prog

On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Wed, 30 Aug 2023 19:53:02 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-08-30, Spiros Bousbouras <spibou@gmail.com> wrote:
>> > If one is willing to write a wrapper function then why not do it like this :
>> >
>> > struct struct_strcpy {
>> > char * to ;
>> > const char * from ;
>> > }
>> >
>> > and have the wrapper function take as a single argument a pointer to struct
>> > struct_strcpy .This way no changes to the language are needed , everyone can
>> > choose whatever member names they prefer
>>
>> Not according to the rule that struct types in different translation
>> units must havre the same member names if they are to be considered
>> compatible.
>
> Why would anyone choose different member names in different translation
> units ? They just declare the structure once in some header.

OK, I wrongly interpreted "everyone can choose whatever member names
they prefer" means. Not everyone working in the same project,
calling the same function.
>
>> > they can reuse the same structure
>> > object if some members have the same value for different function calls (and
>> > assign to the other members) and they can define a structure with default
>> > values if they so wish.
>> >
>> > Does having named arguments offer anything over this approach ?
>>
>> Pragmatics:
>>
>> - Poor ergonomics of calling functions that take struct-encapsulated
>> tuple arguments instead of individual arguments.
>>
>> - E.g. clumsy for a function to call another function that *almost* takes
>> the same arguments. The incoming struct must be destructured,
>> and the member values used to initialize the new structure.
>
> I don't see how this becomes simpler with named arguments.

void foo(int a, int b, int c)
{
bar(a: c, b: b:, c: a, d: SOME_CONSTANT);
}

vs something like:

void foo(foo_struct args)
{
bar((bar_struct) {a: args.c, b: args.b:, c: args.a, d: SOME_CONSTANT});
}

You're missing syntactic sugar to make it smooth. What I want here
is a translator for a C-with-named-args to C-without-name-args
which generates the latter code from the former.

Another issue is that if a structure takes names args by way
of a structure, then that is not optional, unlike the proposals
for names args which make them optional.

The former foo() could dispense with named args and just call
bar like this:

bar(a, b, c, SOME_CONSTANT);

(If bar is an internal helper in the same module, with the argument
conventions being consistent, why would you bother with named args.)

>> - Reduced diagnosis: all arguments have become optional, because
>> designated initializers are optional! If we add a new parameter by
>> adding a member to the struct, the compiler will not find the places
>> that need a new argument.
>
> Yes this may be an issue. But compilers could warn about it.

Or other solutions, like a declaration mechanism in a struct/enum
which stipulates that certain members must be explicitly initialized
(and so become de facto required arguments when structs are used
as parameter tuples).
>
>> - ABI concerns: binary compatibility now dominated by rules for
>> structure passing.
>>
>> - Poor performance in ABIs that don't use registers for struct passing,
>> even for small structs.
>
> I said
> the wrapper function take as a single argument a pointer to struct

Probably, this is something that projects would decide on a case
by case basis.

Dealing with structs passed by pointer at the ABI level is much more
consistent; you're only dealing with the layout rules. E.g. targetting
a function with a struct pointer argument versus struct argument
via FFI can be easier (in particular if there is no ownership protocol:
caller continues to own).

There is the extra pointer indirection though. We lose the ability
to pass small numbers of scalar parameters via registers.

We don't (necessarily) lose that that with a struct by-value.
It's entirely possible that a struct { int a, b, c, d; } is passed via
four registers.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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?

Spiros Bousbouras <spibou@gmail.com> writes:

> On Mon, 28 Aug 2023 16:49:21 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> I favor a different approach to this problem:
>>>>
>>>> static inline char *
>>>> copy_to_from( char *to, const char *from ){
>>>> return strcpy( to, from );
>>>> }
>>>>
>>>> with no language changes needed. And people are still free to
>>>> use the more concise form if they so desire.
>>>
>>> But if we change the names used in the standard for strcpy's parameters,
>>
>> Part of the point of my approach is that it doesn't need any
>> changes to the C standard.
>>
>>> there's no need for a wrapper function (with, in your approach, a name
>>> that doesn't suggest that it operates on strings).
>>
>> That's incidental. It could be copy_string_to_from();
>>
>>> Your wrapper would be useful only if the language added named arguments,
>>> yes?
>>
>> Not at all, that's the point. The function name indicates where
>> the destination (to) and source (from) arguments go. There is
>> no reason a declaration has to use those names, or any names at
>> all, for the function parameters. All the information needed
>> is present in the name of the function.
>
> If one is willing to write a wrapper function then why not do it
> like this :
>
> struct struct_strcpy {
> char * to ;
> const char * from ;
> }
>
> and have the wrapper function take as a single argument a pointer
> to struct struct_strcpy . [...]

Because it's needlessly clunky, and adds annoying visual clutter
at every call site.

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.

Feel free to take the above either as just statements of
personal opinion or as unsubstantiated beliefs.

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:
>>
>>> 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.)
>>
>> In Annex J, J.5.2 gives adding $ to the set of characters that
>> can appear in identifiers as an example of a common extension.
>
> C90 says the same thing in its Annex G. Looks like they didn't update
> it when C99 updated the syntax for an identifier.

Certainly it's true that this passage wasn't changed. That doesn't
mean it wasn't reviewed; it may have been deliberately left in.
There have been lots of opportunities to change it, and it hasn't
been changed yet.

> (Though I suppose an
> implementation could accept $ in identifiers either as an extension or
> as an "other implementation-defined character".)

Yes, no question about it. Furthermore implementors might make one
choice or the other, depending on how they think of the character(s)
in question. For myself, I expect I would naturally think of adding
characters from another alphabet in the implementation-defined
sense, but think of adding $ in the extension sense. Having both
options has some value, in terms of conveying mindset.

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

[..syntax for identifiers...]

> One odd thing (in both N1570 and N3096) is that the Semantics
> subsection uses "shall". For example, N1570 6.4.2.1p3 says:
>
> Each universal character name in an identifier shall designate
> a character whose encoding in ISO/IEC 10646 falls into one of
> the ranges specified in D.1. The initial character shall not
> be a universal character name designating a character whose
> encoding falls into one of the ranges specified in D.2.
>
> This implies that a violation of such a requirement has undefined
> behavior. I would have expected it to be a syntax error.

Clearly the idea is that implementations be allowed to choose
what other universal character names, if any, are to be permitted
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
character names might serve some other purpose, not being part
of the identifier but not necessarily causing an error either.
Apparently anything less than undefined behavior was thought to
be too limiting.

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.

It isn't "euphonic".

"White and black" is also valid English syntax; we prefer to hear "black
and white".

When we hear "white and black", we wonder, is it a proper name?
"White and Black, Barristers and Solicitors" or something?

> 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.

Even if the Smalltalk connection is true, the influence is
probably by way of the Pascal family languages. These use
CamelCase. For instance see the "Turbo Pascal® - Reference Guide"
on bitsavers.org.

Was the Pascal world afflicted with SmallTalk envy? It's hard
to say. But Niklaus Wirth's Pascal report from 1970 already shows
hints of the nucleation of CamelCase; it contains instances
of capitalized identifiers like Boolean, Power, and whatnot.

CamelCase was used in implementing Microsoft Windows, and also
MIT XWindow, and in Apple operating systems. Apple notably used
Pascal in the 1980s an important systems language.

Microsoft's AFX, later renamed MFC, uses CamelCase. This helps
it blend in with Win32.

ISO C++ doesn't use CamelCase; it has snake case like
std::basic_string<>, and static_cast.

I don't recall seeing CamelCase in Stroustrup's books like
the _C++ Annotated Reference Manual_ (ARM "brown book" co-authored
with Margaret Ellis or his other books).

I'm looking (in Google Books) inside _C++ Primer_ by Stanley Lippman, Barbara
Moo, et al, fifth ed with C++11. All I see is snake_case, though
I managed to spy an instance of Camel_snake.

In Andrew Koenig's _Accelerated C++_ I see things like Vec,
Number and Student_info. But not Student_Info or StudentInfo.

Aha! C++ influencer Scott Meyers appears to be a culprit in spreading
the practice. Looking into _Effective C++_, I see that it is teeming
with Dromedaries and BacTrians.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 30/08/2023 21:41, Kaz Kylheku wrote:
> On 2023-08-30, David Brown <david.brown@hesbynett.no> wrote:
>> On 30/08/2023 14:04, Malcolm McLean wrote:
>>> You call the standard library in most C projects.
>>
>> You do not /write/ the standard library for most C projects.
>>
>>> So the argument is that you should match the standard library style.
>>
>> The argument is worthless.
>>
>>> The alternative argument is that you should deliberately not match
>>> the standard library style, to make it obvious which calls are standard
>>> library calls and which are not.
>>
>> That is equally worthless as an argument.
>
> Coding conventions are arbitrarily chosen, an enforced not by arguments
> but authority: ranging from "your patch is rejected" to "write like this
> or find work somewhere else".
>

Coding conventions should certainly /not/ be chosen arbitrarily. But
once chosen, it is usually important to follow them (or to justify cases
where you deviate from them).

Considerations when choosing a coding convention include branch norms,
application area, existing projects, team makeup (including experience
levels), enforceability, and compatibility with other languages.
Sometimes price is a factor too - there are commercially available
coding standards.

The details of coding conventions themselves should be take into account
readability, maintainability, safety, tool options, and target details,
amongst other things. Some coding conventions are very loose and cover
only a few points, others are detailed and rigid.

As much as possible, all choices involved should be active decisions
based on good arguments - not arbitrarily chosen.

> But there exists a consistency argument: if you don't conform to the
> coding convention, then code becomes harder to work with. (As real
> experience with mixed style codebases informs us.)

Yes.

>
> If the naming recommended by the coding convention is at odds with the
> language, then that prevents maximal consistency from being reached.
>

Yes.

That is an issue for some languages, where there are restrictions on the
identifiers. If your project involves several languages, and some have
specific requirements (such as types start with capitals, or variables
must start with a lower case letter), consistency can be hard.
Fortunately, C has no conventions or rules (other than the characters
allowed), so you will never be "at odds" with the C language.

> If consistency is good, globally maximal consistency is better than
> locally maximal consistency.
>

No, not necessarily. Or at least, the consistency is not a major factor
compared to other concerns.

> Thus there is exists a consistency argument against choosing
> a CamelCase naming convention in a brand new C project with zero
> legacy code.
>

I agree there is such an argument - and it is worth considering. After
due consideration, I think it is a worthless argument.

There is no standard in C in regards to naming convention except for
having macros named in all-caps. (And I think that convention is a bad
one, and do not follow it because I rate other factors as more important
than consistency with a poor choice.)

Now, if you want to argue that you find CamelCase (or camelCase) harder
to read, then that is a /good/ argument. Again, it might not be the
overriding factor - but it is a far better reason than "global
consistency" with some pure imaginary "global C standard".

On 30/08/2023 22:07, Spiros Bousbouras wrote:
> On Wed, 30 Aug 2023 19:53:02 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:

>> - ABI concerns: binary compatibility now dominated by rules for
>> structure passing.
>>
>> - Poor performance in ABIs that don't use registers for struct passing,
>> even for small structs.
>
> I said
> the wrapper function take as a single argument a pointer to struct
>

The wrapper function could be an inline function in a header, along with
the struct definition. Then there would be no ABI concerns because only
the original ABI is used - any overheads due to the struct and and
wrapper disappear.

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." [...]
>
> 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's a silly idea. Without imposing any limitations on what
may be included or excluded, a "non-conforming extension" could
be anything (literally anything) at all. It could look like C.
It could look like Fortran, or Ada. It could /be/ Fortran or
Ada. It could look exactly like C, but always have undefined
behavior. Or it could look exactly like C, but always just exit
immediately (with EXIT_SUCCESS on Tuesdays, and EXIT_FAILURE the
rest of the time). None of these possibilities merit being
called an extension of C, non-conforming or otherwise.

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.