SL> I'd wager that most C programmers don't even think about it, much
SL> less care.

I personally kinda like the _t, it makes it stand out a bit because i name
vars stuff like "size" all the time.

-----------------------------------
user is generated from /dev/urandom

On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote:
>
> Ritchie didn't use long identifiers much - and when he did, he used
> underscores.
>
Here's some code by K and R. Either by Ritchie or agreed to by Ritchie.

#include <stdio.h>
#define MAXLINE 1000 /* maximum input line length */
int getline(char line[], int max)
int strindex(char source[], char searchfor[]);
char pattern[] = "ould"; /* pattern to search for */
/* find all lines matching pattern */
main()
{ char line[MAXLINE];
int found = 0;
while (getline(line, MAXLINE) > 0)
if (strindex(line, pattern) >= 0) {
printf("%s", line);
found++;
} return found;
} /* getline: get line into s, return length */
int getline(char s[], int lim)
{ int c, i;
i = 0;
while (--lim > 0 && (c=getchar()) != EOF && c != '\n')
s[i++] = c;
if (c == '\n')
s[i++] = c;
s[i] = '\0';
return i;
} /* strindex: return index of t in s, -1 if none */
int strindex(char s[], char t[])
{ int i, j, k;
for (i = 0; s[i] != '\0'; i++) {
for (j=i, k=0; t[k]!='\0' && s[j]==t[k]; j++, k++)
61
; if (k > 0 && t[k] == '\0')
return i;
} return -1;
}

You see quite clearly that the style used is to avoid underscores.
>
> Not that either of these appeals to authority have any relevance.
>
You don't really understand the "authority" fallacy.
Denis Ritchie's opinion that const was a bad idea doesn't make it true that
const was a bad idea. His opinion that Coke is nicer than Pepsi would
however make it true that Coke is nicer than Pepsi, for him.

See the difference?

On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
> [...]
> >> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
> >> would be to call it "multiplymatrixwithvector".
> >>
> > Well Caesar disagreed.
> Let's drop the lengthy discussions of ancient writing systems, shall we?
> (And David, please stop encouraging them.)
>
For about two thousand years, text was written without spaces. Any rational
person, to whom this was pointed out, would accept that that is prima facie
evidence that it is not that difficult to read. However David Brown has got to
try to make out that the reason the style was adopted was to make it harder
for slaves to read confidential documents. It's beyond absurd.

On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote:
> >> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT)
> >> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> >> > Of course size_t has an underscore. Everyone knows that. And most people
> >> > agree that it is horrible.
> >> "Most people" meaning you made it up.
> >>
> > We could do a straw poll.
> > How many people like the underscore in size_t and how many think it is
> > horrible?
> Did you really just set up a false dichotomy to try to tip the results?
> The question should be simply whether you agree that it's horrible or
> not. You don't have to actually like it to not agree that it's
> horrible.
>
That's a mathematician thinking. "Not horrible" is the complentary set to
"horrible" and thus should be the other choice.
It doesn't work like that.
Bascially "horrible" is a word, whilst "not horrible" is not.

On 26/08/2023 03:26, Richard Damon wrote:
> On 8/25/23 9:16 PM, Bart wrote:

>> "." is already used by C for designated initialisers for structs. Why
>> not just use that?
>
> That could work too.
>
> It still have the macro problem (at least for standard headers)

Why only standard headers? People also use third party headers, which
can be massively more expansive that the standard ones. (Standard
headers might be 3-5K lines of code; GTK is 350K lines.)

>> So, if a function uses x and y parameters, they can clash with
>> user-defined macros called 'x' and 'y'?
>
> Of course, C macros are global substitutes.
>
>>
>> But, this is already going to be a problem with arbitrarily named
>> functions in a library, plus variables, types, enums and macros
>> exported from that library.
>
> If the header defines that the indentifies are reserved for its us, then
> the user code won't (or shouldn't) define macros for them.
>
>>
>> If every such parameter name is to be uglified, then there seems
>> little point.
>
> Yes, that was my point for system headers. You would need something like:
>
> strcpy(_Src: p1, _Dst: p2);
>
> since those are reserved names for the implementation.
>
>>
>> One possible answer might be a new kind of token which is
>> ".alphanumeric", where the alphanumeric part is not checked for macro
>> expansion.
>
> except that would impact something like x.y where you may WANT to have a
> macro for the y part.

Actually, in my language I also wanted to have the 'y' in 'x.y' be a macro.

I couldn't make it work. Then I realised that it couldn't work:

* There might be dozens of different record (struct) definitions with
a field called 'y'.

* Creating a global or even module-local macro called 'y' would change
the interpretation of every term 'x.y' where x could be any of those
multiple struct types

*This also applies to C now*. It is exactly the same problem as the
parameter names.

Struct member names ought to be in their own protected namespace. But
global macros can override all them:

#include <stdio.h>

typedef struct {int x,y;} Point;

int main(void) {
Point p = {100, 200};
printf("%d\n", p.y);
}

This program displays "200". Now introduce a macro like this:

#define y "Why"

and every .y member designation is screwed up.

As I said, exactly the same as might happen with keyword parameter
names, but somehow it works.

Mostly because macro names tend to be in capitals.

Conclusion: for C it is a non-issue. Just another of the many quirks and
gotchas that people already work around.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Friday, 25 August 2023 at 12:39:13 UTC+1, David Brown wrote:
>>
>> Ritchie didn't use long identifiers much - and when he did, he used
>> underscores.
>>
>Here's some code by K and R. Either by Ritchie or agreed to by Ritchie.

<elided C code Malcolm attributes to DR>

>
>You see quite clearly that the style used is to avoid underscores.

The old saying, "One Swallow Doesn't make a Summer" applies.

A simple grep of the Unix Version 6 source base shows underscores
in identifiers and structure tags. struct stat is a classic example,
even leaving aside the use of a leading underscore in external symbols.

Perhaps those are all Ken's doing, but your example proves little
about DR's opinions on underscores in identifiers.

if(ip->i_mode & (IFCHR&IFBLK))
ip->i_addr[i] = 0;
ip->i_addr[i] = rcop();
ip->i_mode =& ~ILARG;
ip->i_addr[j] = alloc();
dwrite(ip->i_addr[j], dbuf); else
ip->i_addr[j] = alloc();
dwrite(ip->i_addr[j], dbuf); else
dwrite(ip->i_addr[7], xbuf);
ip->i_mode =| ILARG;
for(i=0; i<sblock.s_isize;-)
i = --sblock.s_nfree;
b = sblock.s_free[i];
if(sblock.s_nfree <= 0) {
sblock.s_nfree = cbuf[0];
sblock.s_free[i] = cbuf[i+1];
if(sblock.s_nfree >= 100) {
cbuf[0] = sblock.s_nfree;
cbuf[i+1] = sblock.s_free[i];
sblock.s_nfree = 0;
sblock.s_free[sblock.s_nfree++] = in;
setup(&nl[0], "_proc");
setup(&nl[1], "_swapdev");

# define b_sp_max 1500
int b_space [ b_sp_max ];
int * b_sp_nxt { b_space };

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>> [...]
>> >> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>> >> would be to call it "multiplymatrixwithvector".
>> >>
>> > Well Caesar disagreed.
>> Let's drop the lengthy discussions of ancient writing systems, shall we?
>> (And David, please stop encouraging them.)
>>
>For about two thousand years, text was written without spaces. Any rational
>person, to whom this was pointed out, would accept that that is prima facie
>evidence that it is not that difficult to read.

The sources I found indicate that it wasn't intended to be read by anyone
other than the person who wrote it.

On 8/26/23 12:17 AM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 8/25/23 10:58 PM, Keith Thompson wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>> On 8/25/23 8:12 PM, Keith Thompson wrote:
>>> [...]
>>>>> Another issue is that library functions can additionally be defined
>>>>> as macros. One solution would be to say that if you use a named
>>>>> parameter association, it bypasses the macro and calls the function
>>>>> -- which could break some contrived macro invocations. Another would
>>>>> be to allow named parameter associations for macro invocations as
>>>>> well as function calls.
>>>>
>>>> The problem would be needing to completely throw out the existing
>>>> phases of translation.
>>>>
>>>> For instance, a translation unit is allowed to have defined something like:
>>>>
>>>> #define s1 x+y(
>>>>
>>>> before including the system headers. so to ignore that macro in that
>>>> context, would need a complete change in how the preprocessor works.
>>>>
>>>> The fact that s1 is in the user namespace says the header can't
>>>> actually have used that name.
>>>>
>>>> This is why actual headers are filled with names that begin with underscores
>>> My suggestion is that if you define s1 as a macro, something like
>>> strcpy(s1: dst, s2: src);
>>> would simply expand the macro, and very likely fail to compile. I don't
>>> think it's likely to be a problem in practice. No existing code uses
>>> the new feature, so in that sense it would be backward compatible.
>>>
>>
>> The problem is that the standard way the system header is defined, is
>> that it will also use that name, and the system header won't compile,
>> which isn't conforming behavior.
>>
>> While the implementtion doesn't need to store the system headers as
>> normal include files, it is a very common way to define them.
>
> Hmm. The standard could say that if you define a parameter name as an
> object-like macro before including a header that declares a function
> with that parameter, the behavior is undefined. In other words,
> standard parameter names would be reserved, but in fewer contexts than
> standard function names. Since parameter names are lowercase, there
> shouldn't be a lot of code using them as macros.
>

Yes, they could, and break the backwards compatibility rule that has
been a fundamental rule for the history of the standard.

Yes, the common coding practice of UPPER CASE for macros limits the
damage, that common coding practice is NOT a "rule", so can't be relied on.

The problem is that there are people who don't follow that rule, and
their code could get broken.

On 8/26/23 6:07 AM, Bart wrote:
> On 26/08/2023 03:26, Richard Damon wrote:
>> On 8/25/23 9:16 PM, Bart wrote:
>
>>> "." is already used by C for designated initialisers for structs. Why
>>> not just use that?
>>
>> That could work too.
>>
>> It still have the macro problem (at least for standard headers)
>
> Why only standard headers? People also use third party headers, which
> can be massively more expansive that the standard ones. (Standard
> headers might be 3-5K lines of code; GTK is 350K lines.)

Because that isn't a problem the standard needs to solve, but the third
party.

The standard has well defined rules of what is each namespace, and there
policy is to follow that as much as possible.

It would be a major backwards incompatible change to suddenly remove a
large number of symbols out of the user macro namespace for parameter names.

"Third party" libraries have always been in a awkward place of not being
allowed to use the "implementation" name space, because, they are not
part of the implementation, so they need to establish their own rules
about what part of user names space they will try to reserve.

>
>>> So, if a function uses x and y parameters, they can clash with
>>> user-defined macros called 'x' and 'y'?
>>
>> Of course, C macros are global substitutes.
>>
>>>
>>> But, this is already going to be a problem with arbitrarily named
>>> functions in a library, plus variables, types, enums and macros
>>> exported from that library.
>>
>> If the header defines that the indentifies are reserved for its us,
>> then the user code won't (or shouldn't) define macros for them.
>>
>>>
>>> If every such parameter name is to be uglified, then there seems
>>> little point.
>>
>> Yes, that was my point for system headers. You would need something like:
>>
>> strcpy(_Src: p1, _Dst: p2);
>>
>> since those are reserved names for the implementation.
>>
>>>
>>> One possible answer might be a new kind of token which is
>>> ".alphanumeric", where the alphanumeric part is not checked for macro
>>> expansion.
>>
>> except that would impact something like x.y where you may WANT to have
>> a macro for the y part.
>
> Actually, in my language I also wanted to have the 'y' in 'x.y' be a macro.
>
> I couldn't make it work. Then I realised that it couldn't work:
>
> * There might be dozens of different record (struct) definitions with
>   a field called 'y'.

Which means that you don't use that for common field names, but would
only be able to use it for something more unique.

>
> * Creating a global or even module-local macro called 'y' would change
>   the interpretation of every term 'x.y' where x could be any of those
>   multiple struct types
>
> *This also applies to C now*. It is exactly the same problem as the
> parameter names.
>
> Struct member names ought to be in their own protected namespace. But
> global macros can override all them:
>

They do, its just that macros, because of when they are processed, don't
respect it.

>     #include <stdio.h>
>
>     typedef struct {int x,y;} Point;
>
>     int main(void) {
>         Point p = {100, 200};
>         printf("%d\n", p.y);
>     }
>
> This program displays "200". Now introduce a macro like this:
>
>     #define y "Why"
>
> and every .y member designation is screwed up.
>
> As I said, exactly the same as might happen with keyword parameter
> names, but somehow it works.
>
> Mostly because macro names tend to be in capitals.
>
> Conclusion: for C it is a non-issue. Just another of the many quirks and
> gotchas that people already work around.

And this is why namespace rules are important.

If the standard defines that a header will define a struture with a
field with a given name, that name can not be a macro when that header
is included. That is part of the rules of the languge.

If the standard doesn't DEFINE the use of that name, then all the names
in the user namespace might be a macro.

If the user messes themselves up by doing it to themselves, its their
own fault, and not the standards. So y would be a bad name for a macro,
as it is so commonly used in code.

On 26/08/2023 15:33, Richard Damon wrote:
> On 8/26/23 6:07 AM, Bart wrote:

>> This program displays "200". Now introduce a macro like this:
>>
>>      #define y "Why"
>>
>> and every .y member designation is screwed up.
>>
>> As I said, exactly the same as might happen with keyword parameter
>> names, but somehow it works.
>>
>> Mostly because macro names tend to be in capitals.
>>
>> Conclusion: for C it is a non-issue. Just another of the many quirks
>> and gotchas that people already work around.
>
>
> And this is why namespace rules are important.
>
> If the standard defines that a header will define a struture with a
> field with a given name, that name can not be a macro when that header
> is included. That is part of the rules of the languge.
>
> If the standard doesn't DEFINE the use of that name, then all the names
> in the user namespace might be a macro.
>
> If the user messes themselves up by doing it to themselves, its their
> own fault, and not the standards. So y would be a bad name for a macro,
> as it is so commonly used in code.

My point is that this bug in the language already exists.

Macro names have module-wide scope, and can be program-wide when used in
a shared header file.

The can override:

* Member names used struct declarations (int y)

* Member names used for access (x.y)

* Member names used for designated initialisers (.y = x)

* Parameter names used in function declarations and definitions

* Local variables names

* Label names

* Struct and enum tags

* Enum names

* Keywords

* Standard type names

* Function names

....

In short, they can already override everything, in a bad way, across
scopes and even reaching into tag and label namespaces. I hadn't even
realised this before, as I was concentrating on x.y.

So, there is no really big deal with using parameter names in
declarations, which are already affected now, for keyword parameters.

The problem affects all code, the majority of which is going to be user
code not system headers.

This then can't be a factor in deciding whether to add keyword parameters.

On 8/26/23 11:27 AM, Bart wrote:
> On 26/08/2023 15:33, Richard Damon wrote:
>> On 8/26/23 6:07 AM, Bart wrote:
>
>>> This program displays "200". Now introduce a macro like this:
>>>
>>>      #define y "Why"
>>>
>>> and every .y member designation is screwed up.
>>>
>>> As I said, exactly the same as might happen with keyword parameter
>>> names, but somehow it works.
>>>
>>> Mostly because macro names tend to be in capitals.
>>>
>>> Conclusion: for C it is a non-issue. Just another of the many quirks
>>> and gotchas that people already work around.
>>
>>
>> And this is why namespace rules are important.
>>
>> If the standard defines that a header will define a struture with a
>> field with a given name, that name can not be a macro when that header
>> is included. That is part of the rules of the languge.
>>
>> If the standard doesn't DEFINE the use of that name, then all the
>> names in the user namespace might be a macro.
>>
>> If the user messes themselves up by doing it to themselves, its their
>> own fault, and not the standards. So y would be a bad name for a
>> macro, as it is so commonly used in code.
>
> My point is that this bug in the language already exists.
>
> Macro names have module-wide scope, and can be program-wide when used in
>  a shared header file.
>
> The can override:
>
> * Member names used struct declarations (int y)
>
> * Member names used for access (x.y)
>
> * Member names used for designated initialisers (.y = x)
>
> * Parameter names used in function declarations and definitions
>
> * Local variables names
>
> * Label names
>
> * Struct and enum tags
>
> * Enum names
>
> * Keywords
>
> * Standard type names
>
> * Function names
>
> ...
>
> In short, they can already override everything, in a bad way, across
> scopes and even reaching into tag and label namespaces. I hadn't even
> realised this before, as I was concentrating on x.y.
>
> So, there is no really big deal with using parameter names in
> declarations, which are already affected now, for keyword parameters.
>
> The problem affects all code, the majority of which is going to be user
> code not system headers.
>
> This then can't be a factor in deciding whether to add keyword parameters.

No, it means it MUST be a factor in deciding on wheter to add keyword
parameters.

You just don't seem to understand the concept of divided namespaces and
maintaining backwards compatibility.

By the rules of engagement the Standards Committe has established, the
standard CAN NOT just appropriate a large portion of a user name space
for the implementation.

One defined namespace is what can a macro name be, and since that
includes sequences of lower case letters (except for names specifically
called out for THAT header as for the implementation, or defined as
keywords), the Standard can't just make "parameter names" use those sort
of identifiers.

The fact that this namespace ignores most of the rest of the language,
so is truely global within a file gives some problems, but is
fundamental to the nature of how the preprocessor works, and is part of
what gives it some of its power.

On 26/08/2023 16:57, Richard Damon wrote:
> On 8/26/23 11:27 AM, Bart wrote:
>> On 26/08/2023 15:33, Richard Damon wrote:
>>> On 8/26/23 6:07 AM, Bart wrote:
>>
>>>> This program displays "200". Now introduce a macro like this:
>>>>
>>>>      #define y "Why"
>>>>
>>>> and every .y member designation is screwed up.
>>>>
>>>> As I said, exactly the same as might happen with keyword parameter
>>>> names, but somehow it works.
>>>>
>>>> Mostly because macro names tend to be in capitals.
>>>>
>>>> Conclusion: for C it is a non-issue. Just another of the many quirks
>>>> and gotchas that people already work around.
>>>
>>>
>>> And this is why namespace rules are important.
>>>
>>> If the standard defines that a header will define a struture with a
>>> field with a given name, that name can not be a macro when that
>>> header is included. That is part of the rules of the languge.
>>>
>>> If the standard doesn't DEFINE the use of that name, then all the
>>> names in the user namespace might be a macro.
>>>
>>> If the user messes themselves up by doing it to themselves, its their
>>> own fault, and not the standards. So y would be a bad name for a
>>> macro, as it is so commonly used in code.
>>
>> My point is that this bug in the language already exists.
>>
>> Macro names have module-wide scope, and can be program-wide when used
>> in   a shared header file.
>>
>> The can override:
>>
>> * Member names used struct declarations (int y)
>>
>> * Member names used for access (x.y)
>>
>> * Member names used for designated initialisers (.y = x)
>>
>> * Parameter names used in function declarations and definitions
>>
>> * Local variables names
>>
>> * Label names
>>
>> * Struct and enum tags
>>
>> * Enum names
>>
>> * Keywords
>>
>> * Standard type names
>>
>> * Function names
>>
>> ...
>>
>> In short, they can already override everything, in a bad way, across
>> scopes and even reaching into tag and label namespaces. I hadn't even
>> realised this before, as I was concentrating on x.y.
>>
>> So, there is no really big deal with using parameter names in
>> declarations, which are already affected now, for keyword parameters.
>>
>> The problem affects all code, the majority of which is going to be
>> user code not system headers.
>>
>> This then can't be a factor in deciding whether to add keyword
>> parameters.
>
> No, it means it MUST be a factor in deciding on wheter to add keyword
> parameters.
>
> You just don't seem to understand the concept of divided namespaces and
> maintaining backwards compatibility.
>
> By the rules of engagement the Standards Committe has established, the
> standard CAN NOT just appropriate a large portion of a user name space
> for the implementation.
>
> One defined namespace is what can a macro name be, and since that
> includes sequences of lower case letters (except for names specifically
> called out for THAT header as for the implementation, or defined as
> keywords), the Standard can't just make "parameter names" use those sort
> of identifiers.
>
> The fact that this namespace ignores most of the rest of the language,
> so is truely global within a file gives some problems, but is
> fundamental to the nature of how the preprocessor works, and is part of
> what gives it some of its power.
>

So what would happen if this feature was introduced overnight? That is,
instead of doing this which is valid C code now:

void fred(int a, int b, int c);

fred(10, 20, 30);

you were able to do:

fred(10, c:30, b:20);

Bear mind that defining either b or c as non-function-like macros can
already cause problems now, especially if the macro expansion is not a
valid parameter name.

If you say, you wouldn't use parameter names in a declaration, then the
problem occurs here too:

void fred(int a, int b, int c) { ... }
...

fred(10, 20, 30);

As I see it, nothing much changes. How would it affect backwards
compatibility?

Adding a parameter name 'b' in a program that already defines 'b' as a
macro that will be expanded, will cause an immediate problem. Then you
fix that.

On 8/26/23 12:11 PM, Bart wrote:
> On 26/08/2023 16:57, Richard Damon wrote:
>> On 8/26/23 11:27 AM, Bart wrote:
>>> On 26/08/2023 15:33, Richard Damon wrote:
>>>> On 8/26/23 6:07 AM, Bart wrote:
>>>
>>>>> This program displays "200". Now introduce a macro like this:
>>>>>
>>>>>      #define y "Why"
>>>>>
>>>>> and every .y member designation is screwed up.
>>>>>
>>>>> As I said, exactly the same as might happen with keyword parameter
>>>>> names, but somehow it works.
>>>>>
>>>>> Mostly because macro names tend to be in capitals.
>>>>>
>>>>> Conclusion: for C it is a non-issue. Just another of the many
>>>>> quirks and gotchas that people already work around.
>>>>
>>>>
>>>> And this is why namespace rules are important.
>>>>
>>>> If the standard defines that a header will define a struture with a
>>>> field with a given name, that name can not be a macro when that
>>>> header is included. That is part of the rules of the languge.
>>>>
>>>> If the standard doesn't DEFINE the use of that name, then all the
>>>> names in the user namespace might be a macro.
>>>>
>>>> If the user messes themselves up by doing it to themselves, its
>>>> their own fault, and not the standards. So y would be a bad name for
>>>> a macro, as it is so commonly used in code.
>>>
>>> My point is that this bug in the language already exists.
>>>
>>> Macro names have module-wide scope, and can be program-wide when used
>>> in   a shared header file.
>>>
>>> The can override:
>>>
>>> * Member names used struct declarations (int y)
>>>
>>> * Member names used for access (x.y)
>>>
>>> * Member names used for designated initialisers (.y = x)
>>>
>>> * Parameter names used in function declarations and definitions
>>>
>>> * Local variables names
>>>
>>> * Label names
>>>
>>> * Struct and enum tags
>>>
>>> * Enum names
>>>
>>> * Keywords
>>>
>>> * Standard type names
>>>
>>> * Function names
>>>
>>> ...
>>>
>>> In short, they can already override everything, in a bad way, across
>>> scopes and even reaching into tag and label namespaces. I hadn't even
>>> realised this before, as I was concentrating on x.y.
>>>
>>> So, there is no really big deal with using parameter names in
>>> declarations, which are already affected now, for keyword parameters.
>>>
>>> The problem affects all code, the majority of which is going to be
>>> user code not system headers.
>>>
>>> This then can't be a factor in deciding whether to add keyword
>>> parameters.
>>
>> No, it means it MUST be a factor in deciding on wheter to add keyword
>> parameters.
>>
>> You just don't seem to understand the concept of divided namespaces
>> and maintaining backwards compatibility.
>>
>> By the rules of engagement the Standards Committe has established, the
>> standard CAN NOT just appropriate a large portion of a user name space
>> for the implementation.
>>
>> One defined namespace is what can a macro name be, and since that
>> includes sequences of lower case letters (except for names
>> specifically called out for THAT header as for the implementation, or
>> defined as keywords), the Standard can't just make "parameter names"
>> use those sort of identifiers.
>>
>> The fact that this namespace ignores most of the rest of the language,
>> so is truely global within a file gives some problems, but is
>> fundamental to the nature of how the preprocessor works, and is part
>> of what gives it some of its power.
>>
>
> So what would happen if this feature was introduced overnight? That is,
> instead of doing this which is valid C code now:

The effect would be that the parameter names for functions defined in
standard headers would need to be names in spaces that the user was not
allowed to define macros for.

Thus, if your "fred" below was a function defined by the standard, the
parameter names could NOT be "a", "b", or "c", but something like:

void fred(int _A, int _B, int _C);

since names that begin with an underscore, and followed by an upper case
leter are reserved for the implementation, including in macro namespace.

>
>
>      void fred(int a, int b, int c);
>
>      fred(10, 20, 30);
>
> you were able to do:
>
>      fred(10, c:30, b:20);
>
> Bear mind that defining either b or c as non-function-like macros can
> already cause problems now, especially if the macro expansion is not a
> valid parameter name.

And for user code, the user needed to have taken care of that already.

>
> If you say, you wouldn't use parameter names in a declaration, then the
> problem occurs here too:
>
>      void fred(int a, int b, int c) { ...  }
>      ...
>
>      fred(10, 20, 30);
>
> As I see it, nothing much changes. How would it affect backwards
> compatibility?
>
> Adding a parameter name 'b' in a program that already defines 'b' as a
> macro that will be expanded, will cause an immediate problem. Then you
> fix that.
>

You just don't seem to understand the difference between implementation
code and user code.

The user has always had the requirement not to break his own code, and
had rules to follow to keep them from breaking implementation code, or
for implementation code from breaking theirs. That is what the
identifier namespace rules provide.

The side affect of this, is that adding a new use of identifier (the
names of parameters) means the system functions defined by the
implementation must use names that belong to the implementation.

Thus, a function like strcpy CAN'T have "parameter names" like src, as
those are user space names.

On 26/08/2023 11:55, Malcolm McLean wrote:
> On Friday, 25 August 2023 at 19:50:42 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Friday, 25 August 2023 at 09:50:32 UTC+1, Spiros Bousbouras wrote:
>>>> On Fri, 25 Aug 2023 01:37:38 -0700 (PDT)
>>>> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>>>> Of course size_t has an underscore. Everyone knows that. And most people
>>>>> agree that it is horrible.
>>>> "Most people" meaning you made it up.
>>>>
>>> We could do a straw poll.
>>> How many people like the underscore in size_t and how many think it is
>>> horrible?
>> Did you really just set up a false dichotomy to try to tip the results?
>> The question should be simply whether you agree that it's horrible or
>> not. You don't have to actually like it to not agree that it's
>> horrible.
>>
> That's a mathematician thinking.

Do you realise that this is a compliment? You write as though you meant
it as criticism, but Ben's rational and logical thinking is a good thing
- it's certainly far better than your politician "thinking".

> "Not horrible" is the complentary set to
> "horrible" and thus should be the other choice.

No.

The opposite of "think it is horrible" is "do not think it is horrible".
It is not "think it is not horrible". But even that is vastly closer
than "like it".

> It doesn't work like that.

I have no idea what you think "it" is, or how you think "it" might or
might not work - but I strongly suspect you are wrong nonetheless.

> Bascially "horrible" is a word, whilst "not horrible" is not.

And the relevance of that is ... absolutely nothing.

Please try again to answer Ben's question (or mine in an earlier post,
which was much the same). Do you know what a false dichotomy is? Do
you understand that your "straw poll" is a false dichotomy? Do you
realise that false dichotomies are used to try to provoke an answer that
appears to support a particular position, but does not represent a real
model of viewpoints?

Yes/no answers will do - but if you want to elaborate, please at least
attempt to answer the questions.

On 26/08/2023 05:26, Malcolm McLean wrote:
> On Saturday, 26 August 2023 at 03:55:53 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> However that's not the explanation for isdigit() rather than is_digit().
>> I should have said 6 *significant* characters, so is_digit and
>> is_digest might be treated as the same identifier. The early limits
>> on external identifiers forced terse names for library functions.
>> Adding underscores for only some function names would not have been
>> helpful. (I haven't checked whether any standard library function
>> names in C90 have underscores, because I don't care that much.)
>>
> What I said to David Brown was that standard library functions were the
> most commonly called functions in C code, and were all written in the
> style I am recommending. He responded by pointing out that some
> rarely used non-function identiifers, not I think in Ritchie's original
> version of C, have underscores. So only half understanding the point.

I'm sure Keith read my post, and so was better able to understand it
than your inaccurate summary.

>
> Underscores have been introduced for a handful of new time and date
> fucntions which have "restart" options, indicated y a "_r" suffix.
>
> Terseness due to the limitations of compilers and linkers at the time
> is part of the explanation, of course. But it could easily have been
> is_digit() rather than "isdigit", and my point stands.

Ifyousaysoitmustbecorrectbecauseitisclearlyeasiertoreadwhentherearenowordbreaks.

On 26/08/2023 17:35, Richard Damon wrote:
> On 8/26/23 12:11 PM, Bart wrote:
>
> The side affect of this, is that adding a new use of identifier (the
> names of parameters) means the system functions defined by the
> implementation must use names that belong to the implementation.
>
> Thus, a function like strcpy CAN'T have "parameter names" like src, as
> those are user space names.

I'm sorry, I don't understand why you keep going on about system functions.

You don't need to touch the system headers. Nobody is forcing those
functions to have parameter names at all, or if they have, needing those
leading underscores removed.

This is a new feature of most use for functions in user-code.

If someone wants to use it for system functions, then they'll need to
use those underscore names. But then, introducing default values for
missing arguments will have a bigger impact. The names are a non-issue.

On 26/08/2023 11:52, Malcolm McLean wrote:
> On Friday, 25 August 2023 at 12:31:44 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> On Friday, 25 August 2023 at 08:46:22 UTC+1, David Brown wrote:
>> [...]
>>>> The only thing /wrong/ - and pretty much everyone thinks it is wrong -
>>>> would be to call it "multiplymatrixwithvector".
>>>>
>>> Well Caesar disagreed.
>> Let's drop the lengthy discussions of ancient writing systems, shall we?
>> (And David, please stop encouraging them.)
>>
> For about two thousand years, text was written without spaces. Any rational
> person, to whom this was pointed out, would accept that that is prima facie
> evidence that it is not that difficult to read. However David Brown has got to
> try to make out that the reason the style was adopted was to make it harder
> for slaves to read confidential documents. It's beyond absurd.

I think I am beginning to understand. You can't read, or won't read, so
it doesn't matter to you whether there are spaces or not.

I enjoy talking about history, and I happen to know a bit about writing
systems - modern and outdated. I had hoped, since you know a bit of
Hebrew and have looked at old texts, that I might have learned something
new. But I was wrong - you have some basic knowledge combined with some
flat-earth ideas, and you haven't actually bothered reading what I
wrote. So time to stop, I think.

On 8/26/23 1:24 PM, Bart wrote:
> On 26/08/2023 17:35, Richard Damon wrote:
>> On 8/26/23 12:11 PM, Bart wrote:
>>
>> The side affect of this, is that adding a new use of identifier (the
>> names of parameters) means the system functions defined by the
>> implementation must use names that belong to the implementation.
>>
>> Thus, a function like strcpy CAN'T have "parameter names" like src, as
>> those are user space names.
>
> I'm sorry, I don't understand why you keep going on about system functions.

Because that was the question I was answering about.

>
> You don't need to touch the system headers. Nobody is forcing those
> functions to have parameter names at all, or if they have, needing those
> leading underscores removed.

But the comment was that the "names" of the paramaters for system
functions WAS defined, by the prototypes listed in the standard itself.

In the standard, every function parameter is given a name so it can be
discussed in the standard.

The problem is that these names in the standard, because currently they
don't actually matter, since they don't need to be the names used in the
actual header/implementation of the functions, aren't reserved for the
implementaiton or from the namespace so reserved.

>
> This is a new feature of most use for functions in user-code.

Says who?

>
> If someone wants to use it for system functions, then they'll need to
> use those underscore names. But then, introducing default values for
> missing arguments will have a bigger impact. The names are a non-issue.
>

The issue is how likely is a feature to be added that has only
"unacceptable" usage for system functions.

I think you can already sort of do this for user functions. Make your
function take a structure as its one and only parameter, and use
structure initialization to assign the values of the parameters.

On 26/08/2023 18:35, Richard Damon wrote:
> On 8/26/23 1:24 PM, Bart wrote:
>> On 26/08/2023 17:35, Richard Damon wrote:
>>> On 8/26/23 12:11 PM, Bart wrote:
>>>
>>> The side affect of this, is that adding a new use of identifier (the
>>> names of parameters) means the system functions defined by the
>>> implementation must use names that belong to the implementation.
>>>
>>> Thus, a function like strcpy CAN'T have "parameter names" like src,
>>> as those are user space names.
>>
>> I'm sorry, I don't understand why you keep going on about system
>> functions.
>
> Because that was the question I was answering about.
>
>>
>> You don't need to touch the system headers. Nobody is forcing those
>> functions to have parameter names at all, or if they have, needing
>> those leading underscores removed.
>
> But the comment was that the "names" of the paramaters for system
> functions WAS defined, by the prototypes listed in the standard itself.
>
> In the standard, every function parameter is given a name so it can be
> discussed in the standard.

Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have
parameter names, but they are 'filename' and 'mode'; I can't see any
underscores.

Are you saying they would need underscores /added/? If so then I've
misunderstood.

Even so, is that really a problem? No current code will be using those
names.

And if I look inside stdio.h belonging to MingW, the names it uses are
already _Filename and _Mode. The problem then is more, getting standard
headers to use the same consistent names, if they don't already do so.

If so, /then/ what is the problem; that the names are ugly? That seems
to be par for the course for C's standard names.

> The problem is that these names in the standard, because currently they
> don't actually matter, since they don't need to be the names used in the
> actual header/implementation of the functions, aren't reserved for the
> implementaiton or from the namespace so reserved.
>
>>
>> This is a new feature of most use for functions in user-code.
>
> Says who?

Says the fact that most code in an application is going to consist of
user-functions.

>>
>> If someone wants to use it for system functions, then they'll need to
>> use those underscore names. But then, introducing default values for
>> missing arguments will have a bigger impact. The names are a non-issue.
>>
>
> The issue is how likely is a feature to be added that has only
> "unacceptable" usage for system functions.

I don't care about system functions with 2 arguments. I care about ones
like CreateWindowEx() with 14 arguments.

I don't want to lose a jolly useful feature because of some hiccup with
system functions.

> I think you can already sort of do this for user functions. Make your
> function take a structure as its one and only parameter, and use
> structure initialization to assign the values of the parameters.

Come on, that is not a feature, it would be an incredibly ugly and
inconvenient hack.

Imagine defining 9000 structs to match the 9000 functions of GTK.

It also doesn't address the issue of default values.

And it will be inefficient: structs are usually passed by reference to a
block of memory, so the arguments are not passed in registers.

True keyword parameters are exactly as efficient as regular argument
passing.

On 2023-08-26, Bart <bc@freeuk.com> wrote:
> My point is that this bug in the language already exists.
>
> Macro names have module-wide scope, and can be program-wide when used in
> a shared header file.

The pitfalls of a token-level preprocessor are thoroughly understood,
hopefully by everyone here.
>
> The can override:
>
> * Member names used struct declarations (int y)

etc. .. yes; that doesn't improve anyone's understanding.

> In short, they can already override everything, in a bad way, across
> scopes and even reaching into tag and label namespaces. I hadn't even
> realised this before, as I was concentrating on x.y.

Yes. According to ISO C, if you define certain kinds of macros
before including a standard header, the behavior is undefined.

> So, there is no really big deal with using parameter names in
> declarations, which are already affected now, for keyword parameters.

Library headers tend to put all private identifiers in the
__* or _[A-Z]* namespace.

This includes all undocumented structure members; such as

char __padding0[16]; // for binary compatibility

and function parameter names (if they are at all present):

int puts(char *__str);

if named parameters are suddenly supported on library functions,
they have to be public.

It's just an influx of names, and those names have to be simple in order
to be effective. They cannot be put into some prefixed namespace,
because that would make them cumbersome.

For instance, for memcpy in <string.h>, you might want nice
short names like:

void memcpy(void *dest, const void *source, size_t size);

So now "dest", "source" and "size" have become reserved in the
macro namespace. Perhaps "dst" and "src" would be nicer.

It might be possible to restrict the vocabulary to just a couple dozen
words that are reused. Anything with a format string uses "format",
anything with a destination buffer "dest", size is always "size" and so
on; a filename can always be "path", string argument always "str" if
there is only one.

If it's just twenty-something new identifiers, it doesn't seem like
a big deal.

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

On 26/08/2023 20:49, Kaz Kylheku wrote:
> On 2023-08-26, Bart <bc@freeuk.com> wrote:
>> My point is that this bug in the language already exists.
>>
>> Macro names have module-wide scope, and can be program-wide when used in
>> a shared header file.
>
> The pitfalls of a token-level preprocessor are thoroughly understood,
> hopefully by everyone here.
>>
>> The can override:
>>
>> * Member names used struct declarations (int y)
>
> etc. .. yes; that doesn't improve anyone's understanding.
>
>> In short, they can already override everything, in a bad way, across
>> scopes and even reaching into tag and label namespaces. I hadn't even
>> realised this before, as I was concentrating on x.y.
>
> Yes. According to ISO C, if you define certain kinds of macros
> before including a standard header, the behavior is undefined.
>
>> So, there is no really big deal with using parameter names in
>> declarations, which are already affected now, for keyword parameters.
>
> Library headers tend to put all private identifiers in the
> __* or _[A-Z]* namespace.
>
> This includes all undocumented structure members; such as
>
> char __padding0[16]; // for binary compatibility
>
> and function parameter names (if they are at all present):
>
> int puts(char *__str);
>
> if named parameters are suddenly supported on library functions,
> they have to be public.

I assume the reason for the underscope (I don't know why there are two
and not one), is so that 'str' is not shadowed by a global macro name
'str' if that happens to be defined before 'puts'.

If 'str' expands to something that isn't an identifier, it can cause a
syntax error.

OK, use a prefix then, if the alternative is not to have the feature at all.

Note that somebody can still define a macro called 'puts'. Note also
that gcc headers (that is, the headers that are associated with my gcc
installation, in case somebody wants to bring that up again), use "_Str"
for the parameter name, with one underscore and a capital letter.

It's not clear what the purpose of these names is, unless they had
keyword parameters already in mind.

>
> It's just an influx of names, and those names have to be simple in order
> to be effective. They cannot be put into some prefixed namespace,
> because that would make them cumbersome.
>
> For instance, for memcpy in <string.h>, you might want nice
> short names like:
>
> void memcpy(void *dest, const void *source, size_t size);
>
> So now "dest", "source" and "size" have become reserved in the
> macro namespace. Perhaps "dst" and "src" would be nicer.

With the feature in place, people can create their own wrapper functions
and make their own choices.

On 8/26/23 3:11 PM, Bart wrote:
> On 26/08/2023 18:35, Richard Damon wrote:
>> On 8/26/23 1:24 PM, Bart wrote:
>>> On 26/08/2023 17:35, Richard Damon wrote:
>>>> On 8/26/23 12:11 PM, Bart wrote:
>>>>
>>>> The side affect of this, is that adding a new use of identifier (the
>>>> names of parameters) means the system functions defined by the
>>>> implementation must use names that belong to the implementation.
>>>>
>>>> Thus, a function like strcpy CAN'T have "parameter names" like src,
>>>> as those are user space names.
>>>
>>> I'm sorry, I don't understand why you keep going on about system
>>> functions.
>>
>> Because that was the question I was answering about.
>>
>>>
>>> You don't need to touch the system headers. Nobody is forcing those
>>> functions to have parameter names at all, or if they have, needing
>>> those leading underscores removed.
>>
>> But the comment was that the "names" of the paramaters for system
>> functions WAS defined, by the prototypes listed in the standard itself.
>>
>> In the standard, every function parameter is given a name so it can be
>> discussed in the standard.
>
> Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have
> parameter names, but they are 'filename' and 'mode'; I can't see any
> underscores.

Right, because currently, to document the function, since the names
don't actually mean anything, they can use whatever is desired to
document the behavior of the function.

In fact, the name used in a prototype, if names are used at all, are
meaningless to the actual function definition

>
> Are you saying they would need underscores /added/? If so then I've
> misunderstood.

If they wanted the documentation to provide the names that could be used
to call the function with "named parameters" they would.

>
> Even so, is that really a problem? No current code will be using those
> names.

But the program might have the statement

#define filename "Foobar"

before included the header, which would break the prototype given in the
header.

>
> And if I look inside stdio.h belonging to MingW, the names it uses are
> already _Filename and _Mode. The problem then is more, getting standard
> headers to use the same consistent names, if they don't already do so.

"Getting" isn't the issue, if they were docuemented that way, the
implementation MUST update (if needed) to the now "standard" name for
the prototype.

>
> If so, /then/ what is the problem; that the names are ugly? That seems
> to be par for the course for C's standard names.

Yes, it says that to used named parameters to standard library
functions, code would be filled with the "ugly" names.

>
>> The problem is that these names in the standard, because currently
>> they don't actually matter, since they don't need to be the names used
>> in the actual header/implementation of the functions, aren't reserved
>> for the implementaiton or from the namespace so reserved.
>>
>>>
>>> This is a new feature of most use for functions in user-code.
>>
>> Says who?
>
> Says the fact that most code in an application is going to consist of
> user-functions.

Maybe for you, but a lot of code calls the standard library a lot, and
one cost to implementing the feature is deciding on how to handle the
standard library, because you really only get one change.

Once you define what the name of the parameters are, it gets much harder
to change it later.

If they take many user names, they will get complaints of broken code.

If they keep them ugly, they will get complaints that they are ugly.

Being committees, this sort of thing goes slow.

>
>>>
>>> If someone wants to use it for system functions, then they'll need to
>>> use those underscore names. But then, introducing default values for
>>> missing arguments will have a bigger impact. The names are a non-issue.
>>>
>>
>> The issue is how likely is a feature to be added that has only
>> "unacceptable" usage for system functions.
>
> I don't care about system functions with 2 arguments. I care about ones
> like CreateWindowEx() with 14 arguments.

Many of my IDEs, will prompt me with the name from the prototype as I
type the call (some even show it inline in the code of the call)

Then you hit the fact that

>
> I don't want to lose a jolly useful feature because of some hiccup with
> system functions.

Well, are you doing anything to actually make it happen?

Ideas don't just happen, but someone needs to take on the job of doing
the groundwork to make it happen,

>
>
>> I think you can already sort of do this for user functions. Make your
>> function take a structure as its one and only parameter, and use
>> structure initialization to assign the values of the parameters.
>
> Come on, that is not a feature, it would be an  incredibly ugly and
> inconvenient hack.

I never said it was pretty, just possible.

Possible but ugly beats can't be done yet.

>
> Imagine defining 9000 structs to match the 9000 functions of GTK.

Yep, but doesn't actually add that many lines of code (relative to the
current code side.

>
> It also doesn't address the issue of default values.

It doesn't have default values for function calls either.

It could adopt C++'s concept of default values for structures as a very
limited version of constructiors.

>
> And it will be inefficient: structs are usually passed by reference to a
> block of memory, so the arguments are not passed in registers.

Depends on the API. some pass "small" structures in registers, so that
could still work. If you have more than can be held in registers, it
isn't that less efficent,

>
> True keyword parameters are exactly as efficient as regular argument
> passing.
>
>

Yes, IF you have it. C doesn't, so a non-existent capability has ZERO
efficiency.

On 8/26/23 5:00 PM, Bart wrote:
> On 26/08/2023 20:49, Kaz Kylheku wrote:
>> On 2023-08-26, Bart <bc@freeuk.com> wrote:
>>> My point is that this bug in the language already exists.
>>>
>>> Macro names have module-wide scope, and can be program-wide when used in
>>>    a shared header file.
>>
>> The pitfalls of a token-level preprocessor are thoroughly understood,
>> hopefully by everyone here.
>>>
>>> The can override:
>>>
>>> * Member names used struct declarations (int y)
>>
>> etc. .. yes; that doesn't improve anyone's understanding.
>>
>>> In short, they can already override everything, in a bad way, across
>>> scopes and even reaching into tag and label namespaces. I hadn't even
>>> realised this before, as I was concentrating on x.y.
>>
>> Yes. According to ISO C, if you define certain kinds of macros
>> before including a standard header, the behavior is undefined.
>>
>>> So, there is no really big deal with using parameter names in
>>> declarations, which are already affected now, for keyword parameters.
>>
>> Library headers tend to put all private identifiers in the
>> __* or _[A-Z]* namespace.
>>
>> This includes all undocumented structure members; such as
>>
>>    char __padding0[16]; // for binary compatibility
>>
>> and function parameter names (if they are at all present):
>>
>>    int puts(char *__str);
>>
>> if named parameters are suddenly supported on library functions,
>> they have to be public.
>
> I assume the reason for the underscope (I don't know why there are two
> and not one), is so that 'str' is not shadowed by a global macro name
> 'str' if that happens to be defined before 'puts'.
>
> If 'str' expands to something that isn't an identifier, it can cause a
> syntax error.
>
> OK, use a prefix then, if the alternative is not to have the feature at
> all.

yes, the parameters need either a double underscore prefix, or an
underscore + upper case letter to be in the implementation name space,
and usable there.

>
> Note that somebody can still define a macro called 'puts'. Note also
> that gcc headers (that is, the headers that are associated with my gcc
> installation, in case somebody wants to bring that up again), use "_Str"
> for the parameter name, with one underscore and a capital letter.

Not an include the header. If you include a header that defines puts,
then the identifer puts becomes reserved for the implementation and the
user can not define a macro by that name (without causeing undefined
behavior).

>
> It's not clear what the purpose of these names is, unless they had
> keyword parameters already in mind.

The biggest purpose of the names is for error messages. IF you pass an
incompatible type to that parameter, it ca

>
>
>
>>
>> It's just an influx of names, and those names have to be simple in order
>> to be effective. They cannot be put into some prefixed namespace,
>> because that would make them cumbersome.
>>
>> For instance, for memcpy in <string.h>, you might want nice
>> short names like:
>>
>>    void memcpy(void *dest, const void *source, size_t size);
>>
>> So now "dest", "source" and "size" have become reserved in the
>> macro namespace. Perhaps "dst" and "src" would be nicer.
>
> With the feature in place, people can create their own wrapper functions
> and make their own choices.
>

And someone needs to put the effort in to show which option is suitable,
so that something like this can move forward.

Since once it is done, the name of the library parameters are defined,
and changing them will be virtually impossible (due to breaking code
compatibility), effort needs to be done to show something is good enough
to live with.

Bart <bc@freeuk.com> writes:
> On 26/08/2023 18:35, Richard Damon wrote:
>> On 8/26/23 1:24 PM, Bart wrote:
[...]
>>> You don't need to touch the system headers. Nobody is forcing those
>>> functions to have parameter names at all, or if they have, needing
>>> those leading underscores removed.
>> But the comment was that the "names" of the paramaters for system
>> functions WAS defined, by the prototypes listed in the standard itself.
>> In the standard, every function parameter is given a name so it can
>> be discussed in the standard.
>
> Is that so? OK, if I look at N1750.PDF, 'fopen' does indeed have
> parameter names, but they are 'filename' and 'mode'; I can't see any
> underscores.

Right, but the names in the standard might as well be comments. They
have no meaning for client code; they're there only for documentation.
(I'm not sure that the standard states this explicitly.)

> Are you saying they would need underscores /added/? If so then I've
> misunderstood.
>
> Even so, is that really a problem? No current code will be using those
> names.

In the implementation I'm currently using, <stdio.h> has:

extern FILE *fopen (const char *__restrict __filename,
const char *__restrict __modes)
__attribute_malloc__ __attr_dealloc_fclose __wur;

Presumably the __restrict is so that the header can be used with pre-C99
compilers, where "restrict" is not a keyword. We can ignore the third
line.

The declaration shown in the standard (as of N1570) is:

FILE *fopen(const char * restrict filename,
const char * restrict mode);

But a conforming implementation can't use that exact declaration.
This is a (contrived) strictly conforming program for a hosted
implementation:

#define filename (
#define mode )
#include <stdio.h>
int main(void) {
puts filename "Hello, world" mode;
}

but it would fail with a syntax error if <stdio.h> used those parameter
names. That's why conforming implementations use different parameter
names (or possibly none).

What's being proposed is to add named function arguments to a future
version of C. With such a change, the parameter names in the standard
headers would become significant. (And perhaps some of them could be
changed; for example strcpy() might use dst and src rather than s1 and
s2.)

The problem is that such a change would break existing strictly
conforming code (unless the standard library headers use reserved names
like __filename and __mode in all parameter declarations, or the feature
is tweaked in some way that would likely make it less useful and/or
harder to implement.

I think that very little actual code would be broken. Most macros in
user code have all-caps names. Still, it's something the committee
would have to consider very seriously.

I don't think any edition of the C standard has completely avoided
breaking existing code. C99 broke all code that depends on implicit
int. C11 broke all code that uses "restrict" as an identifier. C23
breaks all code that uses "bool", "false", or "true" as an identifier.
And so on.

It's likely that named function arguments will not be added to C any
time soon, because nobody has seriously proposed it (this discussion is
not a formal proposal), because it would probably be seen as too big a
change, and because as far as I know no C compilers have implemented it
as an extension. And it would probably require changes to the
preprocessor as well, since library functions can be defined as macros.

But in my opinion (which doesn't count for much), *if* there were a
decision to add named function arguments to a future edition of the C
standard, the fact that some contrived strictly conforming code would
break should not prevent it.

--
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 26/08/2023 22:07, Richard Damon wrote:
> On 8/26/23 3:11 PM, Bart wrote:

>> I don't want to lose a jolly useful feature because of some hiccup
>> with system functions.
>
> Well, are you doing anything to actually make it happen?
>
> Ideas don't just happen, but someone needs to take on the job of doing
> the groundwork to make it happen,

I'm sure there are plenty of people about adding all sorts of extensions
to C, such as with gnu C. They would be better qualified to get things
happening, and better motivated.

For my part, I first used keyword params in a scripting language in the
90s, and added them to my systems language in the last decade.

I have experience of implementation problems and how well the feature
works in practice.

I suppose I could add them to my C compiler as proof of concept, but I
don't have that motivation, and past experience tells me that nobody
cares what I do there; they don't take my stuff seriously. Besides
changes in C take decades to achieve; I will be long dead.

Meanwhile my everyday language has that feature amongst dozens of
others. I've already done the work! Solving obscure and possibly
imaginary problems of backwards compatibility is not interesting to me.

If you want the feature, find a way around it, or work out a compromise.

But I can tell you that you will want default function arguments as a
feature first.

> [using structs for a row of arguments] I never said it was pretty,
just possible.

Another major shortcoming is that it will only work for specially
written functions.

You can't can't for example modify a declaration of an imported function
to retrofit keyword parameters and default values via a 'struct method';
the call mechanism must be unchanged. Or you need to wrap each function
with a new one.