From Newsgroup: comp.lang.c

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Wuns Haerst <[email protected]> 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 <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> 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 <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> 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) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Wuns Haerst <[email protected]> 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) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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 <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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) [email protected]
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 <[email protected]> writes:

Tim Rentsch <[email protected]> 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 <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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 <[email protected]>
wrote:

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

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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 <[email protected]> writes:

On Sat, 31 Jan 2026 03:53:09 +0000
Tristan Wibberley <[email protected]>
wrote:

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

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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
[email protected] (Scott Lurndal) wrote:

Michael S <[email protected]> writes:

On Sat, 31 Jan 2026 03:53:09 +0000
Tristan Wibberley
<[email protected]> wrote:

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

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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 <[email protected]> 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 <[email protected]> writes:

Keith Thompson <[email protected]> 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) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 03/02/2026 12:21, Keith Thompson wrote:

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.

Could be because a wisdom or claim he thinks is a problem for /other/
people appears uncontested in archives.

usenet is not a transient chat, it is a persistent knowledge share;
there are essentially infinite readers over an essentially infinite
spacetime.

That's why necroposting is not sensibly verboten outside of a charter.
--
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 2026-02-05 00:40, Tristan Wibberley wrote:

usenet is not a transient chat, it is a persistent knowledge share;
there are essentially infinite readers over an essentially infinite spacetime.

The Usenet servers I used in the past had some expiry period, so old
articles couldn't be retrieved any more. Until some time ago Google
filled that gap and archived Usenet posts, but Google seems to have
changed that policy not long ago. Are there (preferably free) servers
that still maintain Usenet articles indefinitely?

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 5 Feb 2026 08:10:38 +0100
Janis Papanagnou <[email protected]> wrote:

On 2026-02-05 00:40, Tristan Wibberley wrote:

usenet is not a transient chat, it is a persistent knowledge share;
there are essentially infinite readers over an essentially infinite spacetime.

The Usenet servers I used in the past had some expiry period, so old
articles couldn't be retrieved any more. Until some time ago Google
filled that gap and archived Usenet posts, but Google seems to have
changed that policy not long ago. Are there (preferably free) servers
that still maintain Usenet articles indefinitely?

Janis

Retention time of Ethernal September appears to be "between server'
crashes".
Retention time of novabbs was "As long as the maintainer is alive +
couple of months".


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 05 Feb 2026 08:10:38 +0100, Janis Papanagnou wrote:

On 2026-02-05 00:40, Tristan Wibberley wrote:

usenet is not a transient chat, it is a persistent knowledge share;
there are essentially infinite readers over an essentially infinite
spacetime.

The Usenet servers I used in the past had some expiry period, so old
articles couldn't be retrieved any more. Until some time ago Google
filled that gap and archived Usenet posts,

DejaNews did it first. Then Google bought out DejaNews in order to
populate their Google Groups news history.

but Google seems to have
changed that policy not long ago.

While I regret that Google no longer archives new posts (their old
post archive still exists), I rejoice in that Google no longer
supports posting to usenet through Groups. I noticed a very great
reduction in spam/troll usenet messages when Google dropped out
of the picture.

Are there (preferably free) servers
that still maintain Usenet articles indefinitely?

Janis

--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

[...]

My personal interpretation is that this:

void func(int arr[static 5]) {
}

int main(void) {
int arr[10];
func(arr+5); // OK
// func(arr+6); // UB
}

is valid, because, for example, the last 5 elements of a 10-element >>>>>>> array object can be treated as a 5-element array object. gcc seems >>>>>>> to agree, based on the fact that it warns about func(arr+6) but
not about func(arr+5).

This is a fundamental part of my mental model of C, but in a few >>>>>>> minutes of searching I wasn't able to find explicit wording in the >>>>>>> standard that supports it.

In N1570, 6.7.6.3 p7.

Did you mean to imply that that paragraph supports (or refutes) my
statement? [...]

No. I posted the reference to say that the cited paragraph supports
the conclusion that 'func(arr+6)' is undefined behavior.

I wish you had said so in the first place. Of course func(arr+6) has
undefined behavior. Did anyone in this thread say or imply otherwise?

In my view the same reasoning about the meaning applies to both
cases, so there is no reason to talk about them separately.

Again, of course the behavior of func(arr+6) is undefined. The behavior
of func(arr+5) is less clear *to me*.

"""
A declaration of a parameter as ??array of _type_?? shall
be adjusted to ??qualified pointer to _type_??, where the
type qualifiers (if any) are those specified within the [ and ]
of the array type derivation. If the keyword static also appears
within the [ and ] of the array type derivation, then for each call
to the function, the value of the corresponding actual argument
shall provide access to the first element of an array with at least
as many elements as specified by the size expression.
"""

The question is whether, for example, the last 5 elements of a
10-element array object can be treated as a 5-element array object.
If someone can cite wording in the standard that answers that
question, I'd appreciate it. (I'll be happier if the answer is yes.) >>>>

To me it seems obvious that 6.7.6.3 p7 is meant to cover the
case of 'func(arr+6)' as being undefined behavior.

But that's not the question I was addressing. My question is whether
func(arr+5) has defined behavior, based on whether or not a+5 points to
the *first element* of an array.

To me it seems obvious that 6.7.6.3 p7 is meant to cover the
case of 'func(arr+5)' as satisfying the "shall" requirement,
for the same reasons that it is meant to cover the case of
'func(arr+6)' as being undefined behavior.

It does so only if the argument arr+5 provides access to "the first
element of an array". You seem to think that it's obvious that it does
so, based on the disinction you make between "array" and "array object".

The "based on ..." part of this sentence isn't right. My view here
depends on how array is defined, not on any distinction between
"array" and "array object".

Note that 6.7.6.3 p7 doesn't say "array object", it says just
"array". I believe the choice of wording is neither an accident nor
an oversight.

Then please explain what you see as the difference. Wording in the
standard to support the distinction would be welcome.

Given `int arr[10];`, do the last 5 elements of arr constitute an
"array"? Do they constitute an "array object"? And the same
questions for arr as a whole.

I note that you haven't answered the above questions. They were not rhetorical. I asked them because I thought that answers to those
specific questions would help me to understand the distinction that you
make between "array" and "array object".

My answer to the first two questions is no, and I don't know what
question(s) you mean to ask by the last sentence. I know that
doesn't help you, and that's why I didn't answer.

The meanings follow from a plain understanding of the English
language.

I disagree. Perhaps my understanding of certain combinations of English words differs from yours.

Consider the following example:

typedef struct { int s; float f; } T;

extern void foo( unsigned char blah[ static sizeof(T)-1 ] );

void
bas( T *it ){
foo( (unsigned char *)it + 1 );
}

There is no array object. But surely there is an array (or at
least an array is indicatated, and an array is present if 'it' is
a valid pointer). This example satisfies the "shall" requirement
in 6.7.6.3 p7, despite there being no array object in sight.

Is there no "region of data storage in the execution environment, the contents of which can represent values"? Cannot that region represent
a value of type unsigned char[sizeof(T)-1]? Is a region of data
storage that can represent values of array type not an array object?
Again, none of these questions are rhetorical.

Arrays do not, as a whole, have values. Elements might have values,
but arrays as a whole do not.

Can you define, preferably in something approaching standardese, what
you mean by "array" and by "array object", and in particular how they
differ?

The difference is contextual. A declaration such as 'int a[5];', at
file scope, declares and defines an array object. The value of a
pointer returned by malloc() may be used to access an array of
elements, but there is nothing that says the region of memory
allocated by malloc() is an array object, only that it may be
accessed as an array.

I believe that, in my example above, arr+5 *does* "provide access
to an array" with at least 5 elements. (I also believe that that
"array" is an "array object".) My difficulty is in demonstrating
this based on the normative wording in the standard. *Maybe*
if you could explain the distinction you make between "array" and
"array object" it would help.

Suppose we have a file scope declaration

int foo[10];

and an expression

(foo+5)[-3];

the behavior of the [] operation is described by the implied +
operation in the section for Additive operators, with P being
the subexpression (foo+5). The region of memory corresponding
to the fifth through ninth elements of foo surely is an array,
but it is not the "array object" referred to by that paragraph
in the C standard. This point shows why it is imporant to
distinguish between "array" and "array object". All array
objects are arrays, but not all arrays are array objects, as
those terms are used in the C standard.

For what it's worth I agree the phrasing used is sometimes
sloppy, but that doesn't change the conclusion that the two
phrases may not be used interchangeably.
--- Synchronet 3.21c-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

[...]

Can you define, preferably in something approaching standardese, what
you mean by "array" and by "array object", and in particular how they
differ?

The difference is contextual. A declaration such as 'int a[5];', at
file scope, declares and defines an array object. The value of a
pointer returned by malloc() may be used to access an array of
elements, but there is nothing that says the region of memory
allocated by malloc() is an array object, only that it may be
accessed as an array.

I was looking for *definitions* of the terms "array" and "array
object" that would help me understand how you're using the terms
and how they differ. Examples can be helpful, but I would like to
see definitions that do not depend on examples.

I do not see any such definitions in anything you've written.

The standard defines the terms "object" and "array type". If there's
a definition for the word "array" by itself, I haven't found it.

I believe that, in my example above, arr+5 *does* "provide access
to an array" with at least 5 elements. (I also believe that that
"array" is an "array object".) My difficulty is in demonstrating
this based on the normative wording in the standard. *Maybe*
if you could explain the distinction you make between "array" and
"array object" it would help.

Suppose we have a file scope declaration

int foo[10];

and an expression

(foo+5)[-3];

the behavior of the [] operation is described by the implied +
operation in the section for Additive operators, with P being
the subexpression (foo+5). The region of memory corresponding
to the fifth through ninth elements of foo surely is an array,
but it is not the "array object" referred to by that paragraph
in the C standard. This point shows why it is imporant to
distinguish between "array" and "array object". All array
objects are arrays, but not all arrays are array objects, as
those terms are used in the C standard.

If I understand you correctly, you assert that given

int foo[10];

the region of memory named "foo" is both an "array" and an "array
object" (of type int[10]), but for example the region of memory
containing the last 5 elements of foo is an "array" but not an
"array object". Is that an accurate statement about your view?

I would say that the latter region is a region of memory in the
execution environment, the contents of which can represent a value of
the array type int[5] -- i.e., it can be treated as an array object,
and that it *is* an array object. (A "value", of course, is the
"precise meaning of the contents of an object when interpreted as
having a specific type"; for an array type, that value consists of
the values of its elements.)

[...]
--
Keith Thompson (The_Other_Keith) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21c-Linux NewsLink 1.2