On 2024-04-09, [email protected] <[email protected]> wrote:
On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <[email protected]> wrote:
On 2024-04-08, [email protected] <[email protected]> wrote:
On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <[email protected]> wrote:
On 08/04/2024 09:47, [email protected] wrote:
What makes you so sure about that? Are you assuming that because /you/ >>>>>are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever >>>> straw men follow.
You wrote, "people like you ... would never use a male pronoun if
talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the >>>argument content.
Mine was correct in general, yours shows you don't understand the difference >> between sexism and realism.
I've not addressed myself to that topic whatsoever, let alone revealed
a position.
On 2024-04-09, Kaz Kylheku <[email protected]> wrote:
On 2024-04-09, [email protected] <[email protected]> wrote:
On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <[email protected]> wrote:
On 2024-04-08, [email protected] <[email protected]> wrote: >>>>> On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <[email protected]> wrote:
On 08/04/2024 09:47, [email protected] wrote:
What makes you so sure about that? Are you assuming that because /you/ >>>>>>are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever >>>>> straw men follow.
You wrote, "people like you ... would never use a male pronoun if >>>>talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the >>>>argument content.
Mine was correct in general, yours shows you don't understand the difference
between sexism and realism.
I've not addressed myself to that topic whatsoever, let alone revealed
a position.
He is easily confused - not worth arguing with.
He is easily confused - not worth arguing with.
If no argument then
patronise
end if
(*) I think the so-called "inclusive language" fad is stupid at best. But like all fads, you can't really fight it. You just have to wait for it to pass (as all fads eventually do).
(*) I think the so-called "inclusive language" fad is stupid at best. But >like all fads, you can't really fight it. You just have to wait for it to >pass (as all fads eventually do).
[email protected] (Kenny McCormack) wrote:
(*) I think the so-called "inclusive language" fad is stupid at best. But >>like all fads, you can't really fight it. You just have to wait for it to >>pass (as all fads eventually do).
The reason woke became so prevelant is because people were too timid to
fight it where it mattered. The end result is it caused polarisation
between left and right and the US ended up with Trump, Poland ended up
with a reactionary right wing government and Hungary still has one.
All this could have been avoided if the grown ups on the left had told
the so called "progressive" kidults who were only ever a tiny minority
to STFU but they didn't because they were and are cowards. And here we
are.
On Tue, 9 Apr 2024 19:51:56 -0000 (UTC)
Jim Jackson <[email protected]> wrote:
On 2024-04-09, Kaz Kylheku <[email protected]> wrote:
On 2024-04-09, [email protected] <[email protected]> wrote:
I've not addressed myself to that topic whatsoever, let alone revealed
a position.
He is easily confused - not worth arguing with.
If no argument then
patronise
end if
On 2024-04-10, [email protected] <[email protected]> wrote:
On Tue, 9 Apr 2024 19:51:56 -0000 (UTC)
Jim Jackson <[email protected]> wrote:
On 2024-04-09, Kaz Kylheku <[email protected]> wrote:
On 2024-04-09, [email protected] <[email protected]> wrote: >>>> I've not addressed myself to that topic whatsoever, let alone revealed >>>> a position.
He is easily confused - not worth arguing with.
If no argument then
patronise
end if
Finally, you are correct. There is indeed no argument with you. The
purpose of an argument is to persuade position changes, using reason.
Why a reasoned position might change is that the reasoning was not
adequately informed in some important point, or contained a mistake; but
a it's a fool's errand to use reason to try to change an unreasoned
position.
In article <uv6abh$11f3e$[email protected]>, <[email protected]> wrote: >>On Wed, 10 Apr 2024 12:46:52 -0000 (UTC)
[email protected] (Kenny McCormack) wrote:
(*) I think the so-called "inclusive language" fad is stupid at best. But >>>like all fads, you can't really fight it. You just have to wait for it to >>>pass (as all fads eventually do).
The reason woke became so prevelant is because people were too timid to >>fight it where it mattered. The end result is it caused polarisation >>between left and right and the US ended up with Trump, Poland ended up
with a reactionary right wing government and Hungary still has one.
All this could have been avoided if the grown ups on the left had told
the so called "progressive" kidults who were only ever a tiny minority
to STFU but they didn't because they were and are cowards. And here we
are.
I can't disagree with any of this.
I can't disagree with any of this.
I forgot Italy - Meloni got voted in precisely as a reaction against the >attempted introduction of so called progressive policies.
On Wed, 10 Apr 2024 16:21:32 -0000 (UTC)
[email protected] (Kenny McCormack) wrote:
In article <uv6abh$11f3e$[email protected]>, <[email protected]> wrote: >>> On Wed, 10 Apr 2024 12:46:52 -0000 (UTC)
The reason woke became so prevelant is because people were too timid to
fight it where it mattered. The end result is it caused polarisation
between left and right and the US ended up with Trump, Poland ended up
with a reactionary right wing government and Hungary still has one.
All this could have been avoided if the grown ups on the left had told
the so called "progressive" kidults who were only ever a tiny minority
to STFU but they didn't because they were and are cowards. And here we
are.
I can't disagree with any of this.
I forgot Italy - Meloni got voted in precisely as a reaction against the attempted introduction of so called progressive policies.
At one time, we distinguished between “scripting” languages and “programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming” languages. Or they were slower, because they were interpreted.
[...]
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, [email protected] 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, [email protected] wrote:
On Sun, 13 Oct 2024 14:29:00 +0200
Janis Papanagnou <[email protected]> boring babbled:
[ X-post list reduced ]
On 13.10.2024 10:18, [email protected] 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 <[email protected]> boring babbled:
[ X-post list reduced ]
On 13.10.2024 10:18, [email protected] 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$[email protected]>, 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$[email protected]>, 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 2024-11-20, Rainer Weikusat <[email protected]> wrote:
Janis Papanagnou <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
Janis Papanagnou <[email protected]> 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;
[email protected] writes:
On 2024-11-20, Rainer Weikusat <[email protected]> wrote:
Janis Papanagnou <[email protected]> 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).
[email protected] writes:
On 2024-11-20, Rainer Weikusat <[email protected]> wrote:
Janis Papanagnou <[email protected]> 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 <[email protected]>,
Rainer Weikusat <[email protected]> wrote:
[email protected] writes:
On 2024-11-20, Rainer Weikusat <[email protected]> wrote:
Janis Papanagnou <[email protected]> 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.
[email protected] (Dan Cross) writes:
In article <[email protected]>,
Rainer Weikusat <[email protected]> wrote:
[email protected] writes:
On 2024-11-20, Rainer Weikusat <[email protected]> wrote:
Janis Papanagnou <[email protected]> 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 <[email protected]>,
Rainer Weikusat <[email protected]> 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 <[email protected]>,
Rainer Weikusat <[email protected]> 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.
[email protected] (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 <[email protected]>,...
James Kuyper <[email protected]> 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.
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 <[email protected]>,...
James Kuyper <[email protected]> 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$[email protected]>,...
James Kuyper <[email protected]> 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]
Here are some ideas for you to consider:
Dan Cross <[email protected]> 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)
[email protected] (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)
[email protected] (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 <[email protected]> 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.
[email protected] (Kalevi Kolttonen) writes:
Dan Cross <[email protected]> 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.
[...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 141:56:51 |
| Calls: | 12,088 |
| Calls today: | 1 |
| Files: | 14,998 |
| Messages: | 6,517,448 |