From Newsgroup: comp.lang.c

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

On 5/14/25 07:00, David Brown wrote:
...

My interpretation matches yours. I can't find any indication in the
standard of a definition of what an "array" actually means

This is a problem with all of the derived types (6.2.5p25). There are definitions of the terms "array type", "structure type:, "union type", "function type", and "pointer type", but no definitions of the things
that those types are types of. My interpretation is that for each of
those object types, "X" is short-hand for "an object of X type".
[...]

That interpretation is not consistent with usage in the standard.
There are at least dozens of places, and probably hundreds of
places, where the C standard refers to pointers, structs, or unions,
but where there is no object. An easy example is the address-of
operator, &. The expression &<something> gives a pointer value, but
just by itself there is no pointer object.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Wuns Haerst <Wuns.Haerst@wurstfabrik.at> writes:
[...]

I think Thiago's idea is brilliant. He should become a
member of the standardization committee. He's welcome
to post suggestions like this here.

If someone wants to propose a revision or addition to the
ISO C standard, the appropriate newsgroup in which to post
it is comp.std.c, not comp.lang.c.

Perhaps, but comp.std.c has no official status with the ISO C
committee. I don't know if any of its members even read it.

I expect none do, but that has no bearing on my comment.

Personally, I'm no longer picky about the division between
comp.lang.c and comp.std.c.

Besides being more faithful to the respective charters, it's
better to steer discussions of changes or additions to the C
standard to comp.std.c for several reasons, the most important
of which are one, the quality of the discussion is likely to be
higher, and two, the quantity of irrelevant noise is likely to
be lower (and that helps comp.lang.c as well as comp.std.c).
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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:

[...]

Read what people write, not what you think they meant.

This rule is a good one for other people too.

Trivially true.

If you have actually something to say to me, say it. Or don't.

My comment was meant generally, not restricted to any
particular individual.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

[...]

Read what people write, not what you think they meant.

This rule is a good one for other people too.

Trivially true.

If you have actually something to say to me, say it. Or don't.

My comment was meant generally, not restricted to any
particular individual.

Then I don't see why you made it.

About 8 months ago, I wrote the above, "Read what people write,
not what you think they meant.", in response to a specific post
by a specific person. It was relevant to a discussion that was
then taking place here on comp.lang.c. (I'm not interested in
resurrecting that long-dead discussion by mentioning any more
details.)

Your followup a month later, "This rule is a good one for other
people too.", was vague and irrelevant to that discussion and
to comp.lang.c. If you had been making a specific point, perhaps
it would have been a useful comment, but apparently you weren't.
Perhaps you think it added something to the discussion. If so,
I disagree.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Wuns Haerst <Wuns.Haerst@wurstfabrik.at> writes:
[...]

I think Thiago's idea is brilliant. He should become a
member of the standardization committee. He's welcome
to post suggestions like this here.

If someone wants to propose a revision or addition to the
ISO C standard, the appropriate newsgroup in which to post
it is comp.std.c, not comp.lang.c.

Perhaps, but comp.std.c has no official status with the ISO C
committee. I don't know if any of its members even read it.

I expect none do, but that has no bearing on my comment.

I say it does.

Someone reading your post (more than 8 months ago) might easily
have inferred that comp.std.c has some official standing with
the ISO C committee. I agree that comp.std.c is probably a more
appropriate place to post suggestions for changes to the standard.
I was adding information, not disagreeing.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]

It isn't just that checking the condition cannot be done in general.
To be reliable the parameter length information would need to be
part of the function's type. That has implications for type
compatibility and also for the types of pointers-to-function. And
it would mean that removing a 'static' array length specification on
a function definition would necessitate also changing the functions
declarations, plus any affected pointers-to-function. Not worth it,
even if in theory it were doable.

[...]

In my opinion, keeping a function's definition and declarations
consistent is absolutely worth it, even if the language might not
require it.

Without some sort of accompanying rationale, this unadorned
statement of opinion conveys no useful information.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[...]

In my opinion, keeping a function's definition and declarations
consistent is absolutely worth it, even if the language might not
require it.

Without some sort of accompanying rationale, this unadorned
statement of opinion conveys no useful information.

I posted an opinion, clearly marked as my opinion. More than
eight months later, you felt the need to post a followup vaguely
expressing your opinion on my opinion.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 28/01/2026 17:54, Tim Rentsch wrote:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

In my opinion, keeping a function's definition and declarations
consistent is absolutely worth it, even if the language might not
require it.

Without some sort of accompanying rationale, this unadorned
statement of opinion conveys no useful information.

That's an ironically appropriate use of "this". If you'd said "that" it wouldn't have been true.
--
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 29/01/2026 00:42, Keith Thompson wrote:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[...]

In my opinion, keeping a function's definition and declarations
consistent is absolutely worth it, even if the language might not
require it.

Without some sort of accompanying rationale, this unadorned
statement of opinion conveys no useful information.

I posted an opinion, clearly marked as my opinion. More than
eight months later, you felt the need to post a followup vaguely
expressing your opinion on my opinion.

You two are awesome at stating mere facts.
I state that.
--
Tristan Wibberley

The message body is Copyright (C) 2026 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sat, 31 Jan 2026 03:53:09 +0000
Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk>
wrote:

On 28/01/2026 17:54, Tim Rentsch wrote:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

In my opinion, keeping a function's definition and declarations
consistent is absolutely worth it, even if the language might not
require it.

Without some sort of accompanying rationale, this unadorned
statement of opinion conveys no useful information.

That's an ironically appropriate use of "this". If you'd said "that"
it wouldn't have been true.

Care to elaborate for the benifit of non-native English readers?
Personally, in this particular context, I don't see how 'this' carries different meaning from 'that'.


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Michael S <already5chosen@yahoo.com> writes:

On Sat, 31 Jan 2026 03:53:09 +0000
Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk>
wrote:

On 28/01/2026 17:54, Tim Rentsch wrote:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

In my opinion, keeping a function's definition and declarations
consistent is absolutely worth it, even if the language might not
require it.

Without some sort of accompanying rationale, this unadorned
statement of opinion conveys no useful information.

That's an ironically appropriate use of "this". If you'd said "that"
it wouldn't have been true.

Care to elaborate for the benifit of non-native English readers?
Personally, in this particular context, I don't see how 'this' carries >different meaning from 'that'.

English is often ambiguous. 'This' in the context of Tim's
response is ambiguous and could be interpreted to refer to
Tim's response itself, rather than to Keith's statement.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sat, 31 Jan 2026 18:33:28 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Michael S <already5chosen@yahoo.com> writes:

On Sat, 31 Jan 2026 03:53:09 +0000
Tristan Wibberley
<tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:

On 28/01/2026 17:54, Tim Rentsch wrote:

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

In my opinion, keeping a function's definition and declarations
consistent is absolutely worth it, even if the language might
not require it.

Without some sort of accompanying rationale, this unadorned
statement of opinion conveys no useful information.

That's an ironically appropriate use of "this". If you'd said
"that" it wouldn't have been true.

Care to elaborate for the benifit of non-native English readers? >Personally, in this particular context, I don't see how 'this'
carries different meaning from 'that'.

English is often ambiguous. 'This' in the context of Tim's
response is ambiguous and could be interpreted to refer to
Tim's response itself, rather than to Keith's statement.

Thank you

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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

[...]

I could write a macro like:

#define ITERATE(var, from, to) for ((var) = (from); (var) < (to); (var)++)

but then anyone reading the code has to understand both how C-style
for loops work and how the ITERATE macro works. Does the expansion
use < or <=? What happens if "to" is INT_MAX? Did the author of
the macro get everything right?

An advantage of using a macro is that these questions need be
answered only once, rather than at every place a for() loop
would appear.

Now if someone else finds that such a macro makes things easier for
them, that's fine. But often, *in my opinion*, such macros make code
harder to read for someone who knows C well.

Whether using a macro like ITERATE() makes code harder to read
or easier to read is a testable proposition, and as such it
deserves to be treated as a question of fact rather than as
a matter of opinion.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

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

[...]

I could write a macro like:

#define ITERATE(var, from, to) for ((var) = (from); (var) < (to); (var)++) >>
but then anyone reading the code has to understand both how C-style
for loops work and how the ITERATE macro works. Does the expansion
use < or <=? What happens if "to" is INT_MAX? Did the author of
the macro get everything right?

An advantage of using a macro is that these questions need be
answered only once, rather than at every place a for() loop
would appear.

Now if someone else finds that such a macro makes things easier for
them, that's fine. But often, *in my opinion*, such macros make code
harder to read for someone who knows C well.

Whether using a macro like ITERATE() makes code harder to read
or easier to read is a testable proposition, and as such it
deserves to be treated as a question of fact rather than as
a matter of opinion.

Did you have anything useful to add? You say it "deserves to be
treated as a question of fact", but you make no attempt to do
so yourself.

You seem to be dredging up old posts of mine (this one is from
about 10 months ago) and finding reasons to complain about them,
usually because the fact that I expressed an opinion bothers you.
I encourage you to knock it off.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2