cross@spitfire.i.gajendra.net (Dan Cross) writes:
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>[...]
>>
>>> In any event, this seems simpler than what you posted:
>>>
>>> #include <stddef.h>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>>
>>> int
>>> main(int argc, char *argv[])
>>> {
>>> if (argc != 2) {
>>> fprintf(stderr, "Usage: matchd <str>\n");
>>> return EXIT_FAILURE;
>>> }
>>>
>>> for (const char *p = argv[1]; *p != '\0'; p++)
>>> if ('0' <= *p && *p <= '9')
>>> return EXIT_SUCCESS;
>>>
>>> return EXIT_FAILURE;
>>> }
>>
>>It's not only 4 lines longer but in just about every individual aspect
>>syntactically more complicated and more messy and functionally more
>>clumsy.
>
> That's a lot of opinion, and not particularly well-founded
> opinion at that, given that your code was incorrect to begin
> with.

That's not at all an opinion but an observation. My opinion on this is
that this is either a poor man's attempt at winning an obfuscation
context or - simpler - exemplary bad code.

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <87cyinrt5s.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>
>>[...]
>>
>>>>Something which would match [0-9]+ in its first argument (if any) would
>>>>be:
>>>>
>>>>#include "string.h"
>>>>#include "stdlib.h"
>>>>
>>>>int main(int argc, char **argv)
>>>>{
>>>> char *p;
>>>> unsigned c;
>>>>
>>>> p = argv[1];
>>>> if (!p) exit(1);
>>>> while (c = *p, c && c - '0' > 10) ++p;
>>>> if (!c) exit(1);
>>>> return 0;
>>>>}
>>>>
>>>>but that's 14 lines of text, 13 of which have absolutely no relation to
>>>>the problem of recognizing a digit.
>>>
>>> Personally, I'd use:
>>>
>>> $ cat /tmp/a.c
>>> #include <stdint.h>
>>> #include <string.h>
>>>
>>> int
>>> main(int argc, const char **argv)
>>> {
>>> char *cp;
>>> uint64_t value;
>>>
>>> if (argc < 2) return 1;
>>>
>>> value = strtoull(argv[1], &cp, 10);
>>> if ((cp == argv[1])
>>> || (*cp != '\0')) {
>>> return 1;
>>> }
>>> return 0;
>>> }
>>
>>This will accept a string of digits whose numerical value is <=
>>ULLONG_MAX, ie, it's basically ^[0-9]+$ with unobvious length and
>>content limits.
>
> He acknowledged this already.
>
>>return !strstr(argv[1], "0123456789");
>>
>>would be a better approximation,
>
> No it wouldn't. That's not even close. `strstr` looks for an
> instance of its second argument in its first, not an instance of
> any character in it's second argument in its first. Perhaps you
> meant something with `strspn` or similar. E.g.,
>
> const char *p = argv[1] + strspn(argv[1], "0123456789");
> return *p != '\0';

My bad.

On 22.11.2024 12:56, Rainer Weikusat wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 20.11.2024 18:50, Rainer Weikusat wrote:
>>>[...]
>>> while (p < e && *p - '0' < 10) ++p;
>>>
>>> That's not too bad. And it's really a hell lot faster than a
>>> general-purpose automaton programmed to recognize the same pattern
>>> (which might not matter most of the time, but sometimes, it does).
>>
>> Okay, I see where you're coming from (and especially in that simple
>> case).
>>
>> Personally (and YMMV), even here in this simple case I think that
>> using pointers is not better but worse - and anyway isn't [in this
>> form] available in most languages;
>
> That's a question of using the proper tool for the job. In C, that's
> pointer and pointer arithmetic because it's the simplest way to express
> something like this.

Yes, in "C" you'd use that primitive (error-prone) pointer feature.
That's what I said. And that in other languages it's less terse than
in "C" but equally error-prone if you have to create all the parsing
code yourself (without an existing engine and in a non-standard way).
And if you extend the expression to parse it's IME much simpler done
in Regex than adjusting the algorithm of the ad hoc procedural code.

>
>> in other cases (and languages)
>> such constructs get yet more clumsy, and for my not very complex
>> example - /[0-9]+(ABC)?x*foo/ - even a "catastrophe" concerning
>> readability, error-proneness, and maintainability.
>
> Procedural code for matching strings constructed in this way is
> certainly much simpler¹ than the equally procedural code for a
> programmable automaton capable of interpreting regexes.

The point is that Regexps and the equivalence to FSA (with guaranteed
runtime complexity) is an [efficient] abstraction with a formalized
syntax; that are huge advantages compared to ad hoc parsing code in C
(or in any other language).

> Your statement
> is basically "If we assume that the code interpreting regexes doesn't
> exist, regexes need much less code than something equivalent which does
> exist." Without this assumption, the picture becomes a different one
> altogether.

I don't speak of assumptions. I speak about the fact that there's a
well-understood model with existing [parsing-]implementations already
available to handle a huge class of algorithms in a standardized way
with a guaranteed runtime-efficiency and in an error-resilient way.

Janis

> [...]

In article <878qtbrs0o.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>
>>>[...]
>>>
>>>> In any event, this seems simpler than what you posted:
>>>>
>>>> #include <stddef.h>
>>>> #include <stdio.h>
>>>> #include <stdlib.h>
>>>>
>>>> int
>>>> main(int argc, char *argv[])
>>>> {
>>>> if (argc != 2) {
>>>> fprintf(stderr, "Usage: matchd <str>\n");
>>>> return EXIT_FAILURE;
>>>> }
>>>>
>>>> for (const char *p = argv[1]; *p != '\0'; p++)
>>>> if ('0' <= *p && *p <= '9')
>>>> return EXIT_SUCCESS;
>>>>
>>>> return EXIT_FAILURE;
>>>> }
>>>
>>>It's not only 4 lines longer but in just about every individual aspect
>>>syntactically more complicated and more messy and functionally more
>>>clumsy.
>>
>> That's a lot of opinion, and not particularly well-founded
>> opinion at that, given that your code was incorrect to begin
>> with.
>
>That's not at all an opinion but an observation. My opinion on this is
>that this is either a poor man's attempt at winning an obfuscation
>context or - simpler - exemplary bad code.

Opinion (noun)
a view or judgment formed about something, not necessarily based on
fact or knowledge. "I'm writing to voice my opinion on an issue of
little importance"

You mentioned snark earlier. Physician, heal thyself.

- Dan C.

In article <874j3zrrxs.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <87cyinrt5s.fsf@doppelsaurus.mobileactivedefense.com>,
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>
>>>[...]
>>>
>>>>>Something which would match [0-9]+ in its first argument (if any) would
>>>>>be:
>>>>>
>>>>>#include "string.h"
>>>>>#include "stdlib.h"
>>>>>
>>>>>int main(int argc, char **argv)
>>>>>{
>>>>> char *p;
>>>>> unsigned c;
>>>>>
>>>>> p = argv[1];
>>>>> if (!p) exit(1);
>>>>> while (c = *p, c && c - '0' > 10) ++p;
>>>>> if (!c) exit(1);
>>>>> return 0;
>>>>>}
>>>>>
>>>>>but that's 14 lines of text, 13 of which have absolutely no relation to
>>>>>the problem of recognizing a digit.
>>>>
>>>> Personally, I'd use:
>>>>
>>>> $ cat /tmp/a.c
>>>> #include <stdint.h>
>>>> #include <string.h>
>>>>
>>>> int
>>>> main(int argc, const char **argv)
>>>> {
>>>> char *cp;
>>>> uint64_t value;
>>>>
>>>> if (argc < 2) return 1;
>>>>
>>>> value = strtoull(argv[1], &cp, 10);
>>>> if ((cp == argv[1])
>>>> || (*cp != '\0')) {
>>>> return 1;
>>>> }
>>>> return 0;
>>>> }
>>>
>>>This will accept a string of digits whose numerical value is <=
>>>ULLONG_MAX, ie, it's basically ^[0-9]+$ with unobvious length and
>>>content limits.
>>
>> He acknowledged this already.
>>
>>>return !strstr(argv[1], "0123456789");
>>>
>>>would be a better approximation,
>>
>> No it wouldn't. That's not even close. `strstr` looks for an
>> instance of its second argument in its first, not an instance of
>> any character in it's second argument in its first. Perhaps you
>> meant something with `strspn` or similar. E.g.,
>>
>> const char *p = argv[1] + strspn(argv[1], "0123456789");
>> return *p != '\0';
>
>My bad.

You've made a lot of "bad"s in this thread, and been rude about
it to boot, crying foul when someone's pointed out ways that
your code is deficient; claiming offense at what you perceive as
"snark" while dishing the same out in kind, making basic errors
that show you haven't done the barest minimum of testing, and
making statements that show you have, at best, a limited grasp
on the language you're choosing to use.

I'm done being polite. My conclusion is that perhaps you are
not as up on these things as you seem to think that you are.

- Dan C.

On Fri, 22 Nov 2024 12:47:16 +0100, Janis Papanagnou wrote:

> On 21.11.2024 23:05, Lawrence D'Oliveiro wrote:
>
>> Another handy one is “\b” for word boundaries.
>
> I prefer \< and \> (that are quite commonly used) for such structural
> things ...

“\<” only matches the beginning of a word, “\>” only matches the end,
“\b” matches both
<https://www.gnu.org/software/emacs/manual/html_node/emacs/Regexp-Backslash.html>.

In article <87o728qzbc.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>mas@a4.home writes:
>> On 2024-11-20, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>
>>> Assuming that p is a pointer to the current position in a string, e is a
>>> pointer to the end of it (ie, point just past the last byte) and -
>>> that's important - both are pointers to unsigned quantities, the 'bulky'
>>> C equivalent of [0-9]+ is
>>>
>>> while (p < e && *p - '0' < 10) ++p;
>>>
>>> That's not too bad. And it's really a hell lot faster than a
>>> general-purpose automaton programmed to recognize the same pattern
>>> (which might not matter most of the time, but sometimes, it does).
>>
>> int
>> main(int argc, char **argv) {
>> unsigned char *p, *e;
>> unsigned char mystr[] = "12#45XY ";
>>
>> p = mystr;
>> e = mystr + sizeof(mystr);
>> while (p < e && *p - '0' < 10) ++p;
>
>The code I'm actually using is
>
> while (p < e && (unsigned)*p - '0' < 10)
> ++p;
>
>I just omitted that when posting this beause I mistakenly assumed that
>it probably wasn't needed, ;-). You could have pointed this out instead
>of trying to dress it up as some sort of mystery problem¹. Especially as
>I did mention that using unsigned arithmetic was necessary (should
>really be self-evident).

Well, no, not exactly. You said that it was important that the
pointers point to unsigned quantities, but that wasn't the
issue. The issue is that both operands of the `-` are promoted
to _signed_ int before the subtraction (sec 6.3.1.8 of n220),
and so the comparison is done against signed quantities. Your
cast fixes this by forcing promotion of '0' and 10 to unsigned
int before either operation.

I do agree that the presentation was overly terse and came off
poorly.

- Dan C.

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <87o728qzbc.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>mas@a4.home writes:
>>> On 2024-11-20, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>
>>>> Assuming that p is a pointer to the current position in a string, e is a
>>>> pointer to the end of it (ie, point just past the last byte) and -
>>>> that's important - both are pointers to unsigned quantities, the 'bulky'
>>>> C equivalent of [0-9]+ is
>>>>
>>>> while (p < e && *p - '0' < 10) ++p;
>>>>
>>>> That's not too bad. And it's really a hell lot faster than a
>>>> general-purpose automaton programmed to recognize the same pattern
>>>> (which might not matter most of the time, but sometimes, it does).
>>>
>>> int
>>> main(int argc, char **argv) {
>>> unsigned char *p, *e;
>>> unsigned char mystr[] = "12#45XY ";
>>>
>>> p = mystr;
>>> e = mystr + sizeof(mystr);
>>> while (p < e && *p - '0' < 10) ++p;
>>
>>The code I'm actually using is
>>
>> while (p < e && (unsigned)*p - '0' < 10)
>> ++p;
>>
>>I just omitted that when posting this beause I mistakenly assumed that
>>it probably wasn't needed, ;-). You could have pointed this out instead
>>of trying to dress it up as some sort of mystery problem¹. Especially as
>>I did mention that using unsigned arithmetic was necessary (should
>>really be self-evident).
>
> Well, no, not exactly. You said that it was important that the
> pointers point to unsigned quantities, but that wasn't the
> issue.

The issue here is that I mistakenly assumed the (unsigned) in the code
was a left-over from before the time when I had changed to pointers to
unsigned char to fix a different issue. As C tries really hard to force
signed arithmetic onto people despite this basically never makes any
sense, the type of '0' is int *p gets promoted to int and hence, the
result of the subtraction will also be an int and the '< 10' condition
will be true for every codepoint numerically less than '9' which
obviously won't work as intended.

That's a mistake I made which would have warranted being pointed out and
possibly explained instead of posting some broken code together with
some output the broken code certainly never generated due it being
broken.

In article <87cyinthjk.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <87o728qzbc.fsf@doppelsaurus.mobileactivedefense.com>,
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>mas@a4.home writes:
>>>> On 2024-11-20, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>>
>>>>> Assuming that p is a pointer to the current position in a string, e is a
>>>>> pointer to the end of it (ie, point just past the last byte) and -
>>>>> that's important - both are pointers to unsigned quantities, the 'bulky'
>>>>> C equivalent of [0-9]+ is
>>>>>
>>>>> while (p < e && *p - '0' < 10) ++p;
>>>>>
>>>>> That's not too bad. And it's really a hell lot faster than a
>>>>> general-purpose automaton programmed to recognize the same pattern
>>>>> (which might not matter most of the time, but sometimes, it does).
>>>>
>>>> int
>>>> main(int argc, char **argv) {
>>>> unsigned char *p, *e;
>>>> unsigned char mystr[] = "12#45XY ";
>>>>
>>>> p = mystr;
>>>> e = mystr + sizeof(mystr);
>>>> while (p < e && *p - '0' < 10) ++p;
>>>
>>>The code I'm actually using is
>>>
>>> while (p < e && (unsigned)*p - '0' < 10)
>>> ++p;
>>>
>>>I just omitted that when posting this beause I mistakenly assumed that
>>>it probably wasn't needed, ;-). You could have pointed this out instead
>>>of trying to dress it up as some sort of mystery problem¹. Especially as
>>>I did mention that using unsigned arithmetic was necessary (should
>>>really be self-evident).
>>
>> Well, no, not exactly. You said that it was important that the
>> pointers point to unsigned quantities, but that wasn't the
>> issue.
>
>The issue here is that I mistakenly assumed the (unsigned) in the code
>was a left-over from before the time when I had changed to pointers to
>unsigned char to fix a different issue.

That you "changed to pointers to unsigned char" is completely
irrelevant. That's not how C works: C will promote those
`unsigned char` values to `signed int` before it does the
subtraction. It does this because `unsigned char` has _rank_
lower than _int_ and the entire range of values is expressible
in a signed int. These are called, "the usual arithmetic
conversions."

I pointed you to the section of the standard that explains this.

>As C tries really hard to force
>signed arithmetic onto people despite this basically never makes any
>sense,

It actually makes a lot of sense in a lot of contexts, and is
usually what people actually want.

You've shown that you, personally, don't have a great command of
the language, so perhaps you shouldn't opine quite so
forcefully.

>the type of '0' is int *p gets promoted to int and hence, the
>result of the subtraction will also be an int and the '< 10' condition
>will be true for every codepoint numerically less than '9' which
>obviously won't work as intended.

Yes, that's how it works.

>That's a mistake I made which would have warranted being pointed out and
>possibly explained instead of posting some broken code together with
>some output the broken code certainly never generated due it being
>broken.

Perhaps if you stopped being so unbearably smug and pretentious
in your judgements people would give you that grace. As it is,
you come across as thin-skinned and terribly insecure, and your
code shows a lack of competence.

- Dan C.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

[...]

>>That's a mistake I made which would have warranted being pointed out and
>>possibly explained instead of posting some broken code together with
>>some output the broken code certainly never generated due it being
>>broken.
>
> Perhaps if you stopped being so unbearably smug and pretentious
> in your judgements people would give you that grace. As it is,
> you come across as thin-skinned and terribly insecure, and your
> code shows a lack of competence.

I suggest you print this and pin to to a place you frequently look
at. This may eventually lead you to a much more realistic assessment of
yourself than you presently seem to have.

On 11/22/24 16:14, Dan Cross wrote:
....
> irrelevant. That's not how C works: C will promote those
> `unsigned char` values to `signed int` before it does the
> subtraction. It does this because `unsigned char` has _rank_
> lower than _int_ ...

True.

> ... and the entire range of values is expressible
> in a signed int.

Not necessarily. An implementation is allowed to have UCHAR_MAX >
INT_MAX, in which case unsigned char promotes to unsigned int rather
than int. I'm aware of systems where UCHAR_MAX > LONG_MAX was true:
char, short, int, and long were all 32 bits.

> ... These are called, "the usual arithmetic
> conversions."

Actually, what you're talking about are the integer promotions. The
first step of the usual arithmetic conversions is to apply the integer
promotions to each operand, but then a few other things happen as well.

On 11/22/24 14:05, Dan Cross wrote:
> In article <87h67zrtns.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@talktalk.net> wrote:...
>> char **argv
>>
>> declares an array of pointers
>
> No, it declares a pointer to a pointer to char.

Agreed.

>> (as each pointer in C points to an array)
>
> That's absolutely not true. A pointer in C may refer to
> an array, or a scalar. Consider,
>
> char c;
> char *p = &c;
> char **pp = &p;

Not actually relevant. For purposes of pointer arithmetic, a pointer to
a single object is treated as if it pointed at the first element of a
1-element array of that object's type.

In article <e47664d3-7f9b-4e67-aa73-b72c6cc0687a@alumni.caltech.edu>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 11/22/24 16:14, Dan Cross wrote:
>...
>> irrelevant. That's not how C works: C will promote those
>> `unsigned char` values to `signed int` before it does the
>> subtraction. It does this because `unsigned char` has _rank_
>> lower than _int_ ...
>
>True.
>
>> ... and the entire range of values is expressible
>> in a signed int.
>
>Not necessarily. An implementation is allowed to have UCHAR_MAX >
>INT_MAX, in which case unsigned char promotes to unsigned int rather
>than int. I'm aware of systems where UCHAR_MAX > LONG_MAX was true:
>char, short, int, and long were all 32 bits.

Yes, but in this context, that's obviously not the case as he
posted the behavior he saw. I was merely explaining _why_ he
saw that behavior, vis the standard.

>> ... These are called, "the usual arithmetic
>> conversions."
>
>Actually, what you're talking about are the integer promotions. The
>first step of the usual arithmetic conversions is to apply the integer
>promotions to each operand, but then a few other things happen as well.

This is correct, but IMHO too far down into the weeds. Consider
section 6.3.1.1 para 3, which notes that, "the integer
promotions are applied only: ... 1. as part of the usual
arithmetic conversions". Since we're talking about operands to
a binary operator, 6.3.1.8 applies. 6.3.1.8 is why converting
one side to unsigned is sufficient to get an unsigned result.

- Dan C.

In article <vhr0fj$1bq0o$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 11/22/24 14:05, Dan Cross wrote:
>> In article <87h67zrtns.fsf@doppelsaurus.mobileactivedefense.com>,
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:...
>>> char **argv
>>>
>>> declares an array of pointers
>>
>> No, it declares a pointer to a pointer to char.
>
>Agreed.
>
>>> (as each pointer in C points to an array)
>>
>> That's absolutely not true. A pointer in C may refer to
>> an array, or a scalar. Consider,
>>
>> char c;
>> char *p = &c;
>> char **pp = &p;
>
>Not actually relevant. For purposes of pointer arithmetic, a pointer to
>a single object is treated as if it pointed at the first element of a
>1-element array of that object's type.

a) Please stop emailing me this stuff _and_ posting it here. I
have asked you this in the past, and previously you'd said that
it was because you switched news readers. That's fine, but that
was a year ago or more.

b) What you are referring to, from the section on Additive
Operators (6.5.7 in n3220; 6.5.6 in C99) is in reference to
pointer arithmetic; the statement that I was replying to was a
general statement about pointers, independent of issues of
pointer arithmetic. That is, it is not the case that, "each
pointer in C points to an array". The above example, to which
you replied, is a counterpoint to the general statement.

So while what you are saying is true, it doesn't change the
general point.

- Dan C.

In article <87cyimapjr.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>[...]
>
>>>That's a mistake I made which would have warranted being pointed out and
>>>possibly explained instead of posting some broken code together with
>>>some output the broken code certainly never generated due it being
>>>broken.
>>
>> Perhaps if you stopped being so unbearably smug and pretentious
>> in your judgements people would give you that grace. As it is,
>> you come across as thin-skinned and terribly insecure, and your
>> code shows a lack of competence.
>
>I suggest you print this and pin to to a place you frequently look
>at. This may eventually lead you to a much more realistic assessment of
>yourself than you presently seem to have.

*shrug* If you don't want to be criticized, don't be wrong so
often. Not my problem if you don't program well.

- Dan C.

On 11/22/24 18:06, Dan Cross wrote:
....
> a) Please stop emailing me this stuff _and_ posting it here. I
> have asked you this in the past, and previously you'd said that
> it was because you switched news readers. That's fine, but that
> was a year ago or more.

Actually, Thunderbird made the change to how the "Reply" button works
sometime around April 2021, and I'm still making the mistake of hitting
it when I should hit "Followup". At my age it's hard to change a habit
acquired over a couple of decades of posting to usenet; I'm doing my
best to change it, and still failing frequently.

I'm unlikely to deliberately send you e-mail, so you can easily avoid
the aggravation of dealing with my accidental e-mails by simply
kill-filing me.

> b) What you are referring to, from the section on Additive
> Operators (6.5.7 in n3220; 6.5.6 in C99) is in reference to
> pointer arithmetic; the statement that I was replying to was a
> general statement about pointers, independent of issues of
> pointer arithmetic. That is, it is not the case that, "each
> pointer in C points to an array". The above example, to which
> you replied, is a counterpoint to the general statement.

I disagree. It is not independent, because there's nothing you can do
with pointer itself that has either it's value or it's validity
dependent upon whether that pointer points at a single object or the
first element of an array of length one.

On 23.11.2024 04:49, James Kuyper wrote:
> On 11/22/24 18:06, Dan Cross wrote:
> ...
>> a) Please stop emailing me this stuff _and_ posting it here. I
>> have asked you this in the past, and previously you'd said that
>> it was because you switched news readers. That's fine, but that
>> was a year ago or more.
>
> Actually, Thunderbird made the change to how the "Reply" button works
> sometime around April 2021, and I'm still making the mistake of hitting
> it when I should hit "Followup". At my age it's hard to change a habit
> acquired over a couple of decades of posting to usenet; I'm doing my
> best to change it, and still failing frequently.

Been there. I desperately looked for a way to fix or alleviate that
horrendous user-interface misconception. Eventually I was able to
fix it, but unfortunately cannot quite recall how that was done.

Now in my old TB 45.8.0 I I have

Followup v Forward ... More v
--------
Reply All
Reply

where Followup is the default and the Reply buttons are a drop-down
menu, while in TB 102.11.0 I have a similar menu like this

Followup v Reply Forward ... More v
-------- ----
Reply All ...
Reply Customize Toolbar

I seem to recall that the leftmost menu items were called something
like *cough* "Smart Reply" (or so), and I indeed see such an entry in
my newer TB version under More -> Customize Toolbar ; maybe it helps
to fix it [on your TB version] (or to find some hints on the Web with
that keyword).

Janis

On 11/22/24 17:34, Dan Cross wrote:
> In article <e47664d3-7f9b-4e67-aa73-b72c6cc0687a@alumni.caltech.edu>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 11/22/24 16:14, Dan Cross wrote:
....
>>> ... and the entire range of values is expressible
>>> in a signed int.
>>
>> Not necessarily. An implementation is allowed to have UCHAR_MAX >
>> INT_MAX, in which case unsigned char promotes to unsigned int rather
>> than int. I'm aware of systems where UCHAR_MAX > LONG_MAX was true:
>> char, short, int, and long were all 32 bits.
>
> Yes, but in this context, that's obviously not the case as he
> posted the behavior he saw. I was merely explaining _why_ he
> saw that behavior, vis the standard.

Your wording could easily give the false impression, to anyone who
didn't already know better, that promotion of unsigned char to signed
int is required by the standard, rather than it being dependent upon
whether UCHAR_MAX > INT_MAX.

>>> ... These are called, "the usual arithmetic
>>> conversions."
>>
>> Actually, what you're talking about are the integer promotions. The
>> first step of the usual arithmetic conversions is to apply the integer
>> promotions to each operand, but then a few other things happen as well.
>
> This is correct, but IMHO too far down into the weeds. Consider
> section 6.3.1.1 para 3, which notes that, "the integer
> promotions are applied only: ... 1. as part of the usual
> arithmetic conversions".

The latest draft of the standard that I have is n3096.pdf, dated
2023-04-01. In that draft, that wording is not present in paragraph 3,
but only footnote 63, which is referenced by paragraph 2. That footnote
does not contain the "1." that is present in your citation. That
footnote goes on to list the other contexts in which integer promotions
can occur: ", to certain argument expressions, to the operands of the
unary +, -, and ~ operators, and to both operands of the shift
operators, as specified by their respective subclauses."
Which version are you quoting? I have copies of most of the draft
standards that are available for free, but none of the final versions of
the standards, since those cost money.

> ... Since we're talking about operands to
> a binary operator, 6.3.1.8 applies. 6.3.1.8 is why converting
> one side to unsigned is sufficient to get an unsigned result.

Calling them the usual arithmetic conversions rather than the integer
promotions is being unnecessarily vague. Your description only covers
the integer promotions, it doesn't cover any of the other usual
arithmetic conversions.

I'm going to try to come up with an analogy; the best one I could come
up on the spur of the moment involves the US federal income tax form
1040. It has a section called "Payments". The first four payments are
all amounts that have been withheld from various income sources before
you ever get a chance to spend the money. Most the other payments are
things that you spent money on that you are entitled to take as a credit
against your tax liability.
What you've done is analogous to describing how withholding works, and
even using the term "withheld", and then referring to what you've just
described as "payments" rather than "amounts withheld", even though your
description doesn't fit the tax credits, which are the other kinds of
payments.

On 11/22/24 23:26, Janis Papanagnou wrote:
> On 23.11.2024 04:49, James Kuyper wrote:
....
>> Actually, Thunderbird made the change to how the "Reply" button works
>> sometime around April 2021, and I'm still making the mistake of hitting
>> it when I should hit "Followup". At my age it's hard to change a habit
>> acquired over a couple of decades of posting to usenet; I'm doing my
>> best to change it, and still failing frequently.
>
> Been there. I desperately looked for a way to fix or alleviate that
> horrendous user-interface misconception. Eventually I was able to
> fix it, but unfortunately cannot quite recall how that was done.

I seem to recall that I was advised that I could use an older version of
Thunderbird to edit the list of buttons that are visible, something that
cannot be done in the latest version. I'm afraid to go back to an older
version, because so many of the updates to most of the software I own
consists of security fixes. I don't want to go back to an older, less
secure version of TB.

On 23.11.2024 06:04, James Kuyper wrote:
> On 11/22/24 23:26, Janis Papanagnou wrote:
>> On 23.11.2024 04:49, James Kuyper wrote:
> ...
>>> Actually, Thunderbird made the change to how the "Reply" button works
>>> sometime around April 2021, and I'm still making the mistake of hitting
>>> it when I should hit "Followup". At my age it's hard to change a habit
>>> acquired over a couple of decades of posting to usenet; I'm doing my
>>> best to change it, and still failing frequently.
>>
>> Been there. I desperately looked for a way to fix or alleviate that
>> horrendous user-interface misconception. Eventually I was able to
>> fix it, but unfortunately cannot quite recall how that was done.
>
> I seem to recall that I was advised that I could use an older version of
> Thunderbird to edit the list of buttons that are visible, something that
> cannot be done in the latest version. I'm afraid to go back to an older
> version, because so many of the updates to most of the software I own
> consists of security fixes. I don't want to go back to an older, less
> secure version of TB.

Understandable. - But you noticed that the "Smart Reply" thing was
a feature of my newer Thunderbird version? - I'd think it should be
there, or isn't it in your version? (What version are you running?)

Janis

On Fri, 22 Nov 2024 18:18:04 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> gabbled:
>On 2024-11-22, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
>> Its not that simple I'm afraid since comments can be commented out.
>
>Umm, no.

Umm, yes, they can.

>> eg:
>>
>> // int i; /*
>
>This /* sequence is inside a // comment, and so the machinery that
>recognizes /* as the start of a comment would never see it.

Yes, thats kind of the point. You seem to be arguing against yourself.

>> A C99 and C++ compiler would see "int j" and compile it, a regex would
>> simply remove everything from the first /* to */.
>
>No, it won't, because that's not how regexes are used in a lexical

Yes, it will.

>> Also the same probably applies to #ifdef's.
>
>Lexically analyzing C requires implementing the translation phases
>as described in the standard. There are preprocessor phases which
>delimit the input into preprocessor tokens (pp-tokens). Comments
>are stripped in preprocessing. But logical lines (backslash
>continuations) are recognized below comments; i.e. this is one
>comment:

Not sure what your point is. A regex cannot be used to parse C comments because
its doesn't know C/C++ grammar.

In article <vhrjcr$1ijr4$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 11/22/24 18:06, Dan Cross wrote:
>...
>> a) Please stop emailing me this stuff _and_ posting it here. I
>> have asked you this in the past, and previously you'd said that
>> it was because you switched news readers. That's fine, but that
>> was a year ago or more.
>
>Actually, Thunderbird made the change to how the "Reply" button works
>sometime around April 2021, and I'm still making the mistake of hitting
>it when I should hit "Followup". At my age it's hard to change a habit
>acquired over a couple of decades of posting to usenet; I'm doing my
>best to change it, and still failing frequently.

Three and a half years is a long time to learn how to use a tool
competently.

>I'm unlikely to deliberately send you e-mail, so you can easily avoid
>the aggravation of dealing with my accidental e-mails by simply
>kill-filing me.

Please don't put the onus to deal with your mistakes on me.

>> b) What you are referring to, from the section on Additive
>> Operators (6.5.7 in n3220; 6.5.6 in C99) is in reference to
>> pointer arithmetic; the statement that I was replying to was a
>> general statement about pointers, independent of issues of
>> pointer arithmetic. That is, it is not the case that, "each
>> pointer in C points to an array". The above example, to which
>> you replied, is a counterpoint to the general statement.
>
>I disagree. It is not independent, because there's nothing you can do
>with pointer itself that has either it's value or it's validity
>dependent upon whether that pointer points at a single object or the
>first element of an array of length one.

You can indirect it without doing arithmetic on it. This isn't
a particularly interesting topic, however. The point was that
the OP's statement was factually incorrect.

- Dan C.

In article <vhrmk1$1ivhr$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 11/22/24 17:34, Dan Cross wrote:
>> In article <e47664d3-7f9b-4e67-aa73-b72c6cc0687a@alumni.caltech.edu>,
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 11/22/24 16:14, Dan Cross wrote:
>...
>>>> ... and the entire range of values is expressible
>>>> in a signed int.
>>>
>>> Not necessarily. An implementation is allowed to have UCHAR_MAX >
>>> INT_MAX, in which case unsigned char promotes to unsigned int rather
>>> than int. I'm aware of systems where UCHAR_MAX > LONG_MAX was true:
>>> char, short, int, and long were all 32 bits.
>>
>> Yes, but in this context, that's obviously not the case as he
>> posted the behavior he saw. I was merely explaining _why_ he
>> saw that behavior, vis the standard.
>
>Your wording could easily give the false impression, to anyone who
>didn't already know better, that promotion of unsigned char to signed
>int is required by the standard, rather than it being dependent upon
>whether UCHAR_MAX > INT_MAX.

Actually I'm not sure that it did. Note the part that you
quoted above that says, "the entire range values is expressible
in a signed int." This implies UCHAR_MAX <= INT_MAX. (By
"values" I meant, "values of that type", not specific values in
any given program).

Regardless, if you wanted to provide more detail, it would be
done more usefully by doing so within the context, "here's why
this is true in this context, but note that other contexts
exist in which this doesn't hold, and here's why..." etc.

>>>> ... These are called, "the usual arithmetic
>>>> conversions."
>>>
>>> Actually, what you're talking about are the integer promotions. The
>>> first step of the usual arithmetic conversions is to apply the integer
>>> promotions to each operand, but then a few other things happen as well.
>>
>> This is correct, but IMHO too far down into the weeds. Consider
>> section 6.3.1.1 para 3, which notes that, "the integer
>> promotions are applied only: ... 1. as part of the usual
>> arithmetic conversions".
>
>The latest draft of the standard that I have is n3096.pdf, dated
>2023-04-01.

As I mentioned, I'm looking at n3220.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

You may want to looka t n3301, which seems to be the latest.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3301.pdf

>In that draft, that wording is not present in paragraph 3,
>but only footnote 63, which is referenced by paragraph 2. That footnote
>does not contain the "1." that is present in your citation. That
>footnote goes on to list the other contexts in which integer promotions
>can occur: ", to certain argument expressions, to the operands of the
>unary +, -, and ~ operators, and to both operands of the shift
>operators, as specified by their respective subclauses."
>Which version are you quoting? I have copies of most of the draft
>standards that are available for free, but none of the final versions of
>the standards, since those cost money.

See above.

>> ... Since we're talking about operands to
>> a binary operator, 6.3.1.8 applies. 6.3.1.8 is why converting
>> one side to unsigned is sufficient to get an unsigned result.
>
>Calling them the usual arithmetic conversions rather than the integer
>promotions is being unnecessarily vague. Your description only covers
>the integer promotions, it doesn't cover any of the other usual
>arithmetic conversions.

The integer promotions were the only relevant part in context.
Perhaps it would have allayed your concerns to say, "part of"?

>I'm going to try to come up with an analogy; the best one I could come
>up on the spur of the moment involves the US federal income tax form
>1040. It has a section called "Payments". The first four payments are
>all amounts that have been withheld from various income sources before
>you ever get a chance to spend the money. Most the other payments are
>things that you spent money on that you are entitled to take as a credit
>against your tax liability.
>What you've done is analogous to describing how withholding works, and
>even using the term "withheld", and then referring to what you've just
>described as "payments" rather than "amounts withheld", even though your
>description doesn't fit the tax credits, which are the other kinds of
>payments.

Sorry, I think this analogy is poor and unhelpful. See the
above references.

- Dan C.

On 11/23/24 00:09, Janis Papanagnou wrote:
> On 23.11.2024 06:04, James Kuyper wrote:
....
>> I seem to recall that I was advised that I could use an older version of
>> Thunderbird to edit the list of buttons that are visible, something that
>> cannot be done in the latest version. I'm afraid to go back to an older
>> version, because so many of the updates to most of the software I own
>> consists of security fixes. I don't want to go back to an older, less
>> secure version of TB.
>
> Understandable. - But you noticed that the "Smart Reply" thing was
> a feature of my newer Thunderbird version? - I'd think it should be
> there, or isn't it in your version? (What version are you running?)

115.16.0esr

I don't have a "More/Customize Toolbar" option, only "More/Customize",
and when I select it, there's only the following options:

Button Style
Show senders profile picture
Larger Profile Picture
Always show sender's full address
Hide Labels Column
Large Subject
Show all Headers

On 11/23/24 09:05, Dan Cross wrote:
> In article <vhrmk1$1ivhr$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> Your wording could easily give the false impression, to anyone who
>> didn't already know better, that promotion of unsigned char to signed
>> int is required by the standard, rather than it being dependent upon
>> whether UCHAR_MAX > INT_MAX.
>
> Actually I'm not sure that it did. Note the part that you
> quoted above that says, "the entire range values is expressible
> in a signed int." This implies UCHAR_MAX <= INT_MAX. (By
> "values" I meant, "values of that type", not specific values in
> any given program).

You paired that assertion with "`unsigned char` has _rank_
lower than _int_", which is a fact guaranteed by the standard, which
could easily give the impression that the comment about the range of
values was either explicitly stated in the standard, or correctly
inferrable from the statement about the ranks.

....
>>> ... Since we're talking about operands to
>>> a binary operator, 6.3.1.8 applies. 6.3.1.8 is why converting
>>> one side to unsigned is sufficient to get an unsigned result.
>>
>> Calling them the usual arithmetic conversions rather than the integer
>> promotions is being unnecessarily vague. Your description only covers
>> the integer promotions, it doesn't cover any of the other usual
>> arithmetic conversions.
>
> The integer promotions were the only relevant part in context.
> Perhaps it would have allayed your concerns to say, "part of"?

Partially. However since you described the integer promotions, and the
description you provided didn't fit any other part of the usual
arithmetic conversions, and the part you described has it's own special
name, and the integer promotions can occur without the usual arithmetic
conversions, it still seems to me more appropriate to say that what you
described were the integer promotions.