| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 94:25:44 |
| Calls: | 290 |
| Calls today: | 1 |
| Files: | 904 |
| Messages: | 76,378 |
[...]
I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in
the day. Not something that can be said for MacOS with its role-our-own
Apple specific way of doing pretty much everything.
[ X-post list reduced ]
On 13.10.2024 10:18, Muttley@DastartdlyHQ.org wrote:
[...]
I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in
the day. Not something that can be said for MacOS with its role-our-own
Apple specific way of doing pretty much everything.
I've never programmed on Mac OS X (if the discussion is about that)
but since its kernel is based on a BSD system it doesn't seem to be
On 13.10.2024 16:03, Muttley@DastartdlyHQ.org wrote:
On Sun, 13 Oct 2024 14:29:00 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
On 13.10.2024 10:18, Muttley@DastartdlyHQ.org wrote:
[...]
I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in >>>> the day. Not something that can be said for MacOS with its role-our-own >>>> Apple specific way of doing pretty much everything.
I've never programmed on Mac OS X (if the discussion is about that)
but since its kernel is based on a BSD system it doesn't seem to be
It isn't. Its a Mach kernel with a BSD compat layer on top. [...]
I've ever only heared that it's based on FreeBSD. From Wikipedia I'm
getting told that the contemporary Darwin (Apple's Unix) was derived
from FreeBSD, supplemented by OpenBSD, NetBSD, and own parts. Anyway,
not worth a dispute (as far as I am concerned).
On Sun, 13 Oct 2024 14:29:00 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
On 13.10.2024 10:18, Muttley@DastartdlyHQ.org wrote:
[...]
I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in >>> the day. Not something that can be said for MacOS with its role-our-own
Apple specific way of doing pretty much everything.
I've never programmed on Mac OS X (if the discussion is about that)
but since its kernel is based on a BSD system it doesn't seem to be
It isn't. Its a Mach kernel with a BSD compat layer on top. [...]
I was speaking about [formal] languages as introduced by Chomsky
Janis Papanagnou , dans le message <vehkbt$s85f$1@dont-email.me>, a
Θcrit :
I was speaking about [formal] languages as introduced by Chomsky
Are we not progressively realizing that most of what Chomsky said was unsubstantiated bullshit?
Janis Papanagnou , dans le message <vehkbt$s85f$1@dont-email.me>, a
écrit :
I was speaking about [formal] languages as introduced by Chomsky
Are we not progressively realizing that most of what Chomsky said was unsubstantiated bullshit?
Given the generalization and lack of any substance in your post, and
the (enduring) relevance of Chomsky's work for computer science your
comment appears to reveal nothing but ignorance (and of course your
offending habits).
And we have found yet another shibboleth for exposing those of a, shall we say, certain backwards-looking political persuasion ...
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 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.
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).
... 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"?
[snip]
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;
size_t xlen = p-mystr;
printf("digits: '%.*s'\n", (int) xlen, mystr);
printf("mystr %p p %p e %p\n", mystr, p, e);
printf("xlen %zd\n", xlen);
return 0;
}
./a.out
digits: '12#45'
mystr 0x7ffc92ac55ff p 0x7ffc92ac5604 e 0x7ffc92ac5608
xlen 5
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).
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;
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;
size_t xlen = p-mystr;
printf("digits: '%.*s'\n", (int) xlen, mystr);
printf("mystr %p p %p e %p\n", mystr, p, e);
printf("xlen %zd\n", xlen);
return 0;
}
./a.out
digits: '12#45'
mystr 0x7ffc92ac55ff p 0x7ffc92ac5604 e 0x7ffc92ac5608
xlen 5
Indeed. Rainer's while loop should be using isdigit(*p).
Indeed. Rainer's while loop should be using isdigit(*p).
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).
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.
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.
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.
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.
(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;
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."
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.
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.
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.
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.
... 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.
Here are some ideas for you to consider:
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Here are some ideas for you to consider:
Sorry for replying to an old post. I do not even
remember who it is that keeps sending emails when
he intends to send follow-ups to Usenet. However,
I have a good solution.
Thunderbird is open source, maybe even free software.
I am sure it is extremely easy to either remove the
"reply" button or to bind it to the "followup" function.
On Fri, 27 Dec 2024 13:59:47 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
I am sure it is extremely easy to either remove the
"reply" button or to bind it to the "followup" function.
Have you, like, actually *checked* this assertion?
On Fri, 27 Dec 2024 13:59:47 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
I am sure it is extremely easy to either remove the
"reply" button or to bind it to the "followup" function.
Have you, like, actually *checked* this assertion?
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Here are some ideas for you to consider:
Sorry for replying to an old post. I do not even
remember who it is that keeps sending emails when
he intends to send follow-ups to Usenet. However,
I have a good solution.
Thunderbird is open source, maybe even free software.
kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Here are some ideas for you to consider:
Sorry for replying to an old post. I do not even
remember who it is that keeps sending emails when
he intends to send follow-ups to Usenet. However,
I have a good solution.
Thunderbird is open source, maybe even free software.
I am sure it is extremely easy to either remove the
"reply" button or to bind it to the "followup" function.
Go on then?
[ Thunderbird issues ]
Thunderbird is yet another mail program whose developers think that
Usenet is just like e-mail, and can be bolted onto a mail client.
[...]