On Monday, September 20, 2021 at 3:25:11 AM UTC-3, Mehdi Amini Valashani son of Bahram wrote:
> Hi,
>
> It seems these are some of changes for C23(C2x) standard taken from
> draft documents:
>
> https://en.cppreference.com/w/c/23
> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>
> What do you think of changes ?
>
> One minor suggestion for me is to have format specifier for bool type in
> printf function. Even though currently the fix is a trivial one.

Something new in C23 are attributes.
One of then is nodiscard :

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf

"
EXAMPLE 2
[[nodiscard]] int important_func(void);
void call(void) {
int i = important_func();
} No diagnostic for the call to important_func is encouraged despite the value of i not being used.
"
[[nodiscard("must check armed state")]]
bool arm_detonator(int);
void call(void) {
arm_detonator(3);
detonate();
}

"A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
clause is encouraged."

This called my attention because the treatment is different for
int or _bool
I have no idea why.

And what is funny is that C++ has
[[noreturn]]
and C (before attributes and after)
_NoReturn.

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> Something new in C23 are attributes.
> One of then is nodiscard :
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
>
> "
> EXAMPLE 2
> [[nodiscard]] int important_func(void);
> void call(void) {
> int i = important_func();
> }
> No diagnostic for the call to important_func is encouraged despite the value of i not being used.
> "
> [[nodiscard("must check armed state")]]
> bool arm_detonator(int);
> void call(void) {
> arm_detonator(3);
> detonate();
> }
>
> "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
> clause is encouraged."
>
> This called my attention because the treatment is different for
> int or _bool
> I have no idea why.

No, there's no difference in the treatment for int and _Bool.

The two relevant examples are:

[[nodiscard]] int important_func(void);
void call(void) {
int i = important_func();
}

No diagnostic for the call to important_func is encouraged despite
the value of i not being used.

and

[[nodiscard("must check armed state")]]
bool arm_detonator(int);
void call(void) {
arm_detonator(3);
detonate();
}

A diagnostic for the call to arm_detonator using the string literal
"must check armed state" from the attribute argument clause is
encouraged.

The difference isn't the types, it's the way the result is used. In the
first example, the result of the function is used to initialize an
object, so it's "used", even though that object's stored value is never
used. In the second example, the result isn't assigned to anything.
The point is that compilers aren't required to do data flow analysis;
any immediate use of the result is enough to turn off the warning. (Of
course compilers can warn about anything they like, and compilers
commonly do warn about unused variables, but that warning isn't
connected to the [[nodiscard]] attribute.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 27/09/2021 20:15, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> [...]
>> Something new in C23 are attributes.
>> One of then is nodiscard :
>>
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
>>
>> "
>> EXAMPLE 2
>> [[nodiscard]] int important_func(void);
>> void call(void) {
>> int i = important_func();
>> }
>> No diagnostic for the call to important_func is encouraged despite the value of i not being used.
>> "
>> [[nodiscard("must check armed state")]]
>> bool arm_detonator(int);
>> void call(void) {
>> arm_detonator(3);
>> detonate();
>> }
>>
>> "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
>> clause is encouraged."
>>
>> This called my attention because the treatment is different for
>> int or _bool
>> I have no idea why.
>
> No, there's no difference in the treatment for int and _Bool.
>
> The two relevant examples are:
>
> [[nodiscard]] int important_func(void);
> void call(void) {
> int i = important_func();
> }
>
> No diagnostic for the call to important_func is encouraged despite
> the value of i not being used.
>
> and
>
> [[nodiscard("must check armed state")]]
> bool arm_detonator(int);
> void call(void) {
> arm_detonator(3);
> detonate();
> }
>
> A diagnostic for the call to arm_detonator using the string literal
> "must check armed state" from the attribute argument clause is
> encouraged.
>
> The difference isn't the types, it's the way the result is used. In the
> first example, the result of the function is used to initialize an
> object, so it's "used", even though that object's stored value is never
> used. In the second example, the result isn't assigned to anything.
> The point is that compilers aren't required to do data flow analysis;
> any immediate use of the result is enough to turn off the warning. (Of
> course compilers can warn about anything they like, and compilers
> commonly do warn about unused variables, but that warning isn't
> connected to the [[nodiscard]] attribute.)
>

Or, I think more accurately, it does not have to be connected to the
attribute. A compiler could choose to warn about "i" not being used in
the first example, precisely because of the attribute, even if it did
not normally warn about unused variables. There is quite a lot of
freedom about how the attributes are actually implemented.

On 9/27/2021 6:38 PM, Ben Bacarisse wrote:
> Manfred <noname@add.invalid> writes:
>
>> On 9/20/2021 7:55 PM, Bart wrote:
>
>>> Of course it makes perfect sense to have a pile of 4294967295 apples,
>>> add another apple to the pile, and suddenly end up with 0 apples!
>>> Meanwhile, someone could remove that extra apple from the pile of
>>> -2147483648, to restore the original 2147483647, however that's too
>>> late: the overflow police have already been, and will do so again
>>> even when it becomes legal.
>>>
>>
>> It's all about modeling a problem domain.
>> In mathematics, /integer/ arithmetic (the one you use a.o. to add and
>> subtract things) is /signed/ (for any serious work, at least). The
>> tool that C offers to model this domain is signed integers - with the
>> unavoidable limitations of limited size.
>>
>> Unsigned integers are the tool that C offers for /binary/
>> arithmetic. In this context wrapping is one of the features that makes
>> them useful.
>
> Some mathematics concerns the natural numbers. Unsigned integer types
> would be an entirely natural (no pun intended) choice for these cases.
>

True, and in fact, while writing the post natural numbers came to mind
as well; for example, in a simple counter unsigned int makes perfect sense.

However, I was following up at Bart's post about what's the point of
adding an apple to a pile of 4294967295 apples and end up with nothing,
which is understandably disappointing, since stocking up that pile of
apples probably took a considerable amount of work...

A couple of considerations:
- How common is the need to model math that is strictly about natural
numbers compared to the need for integer math? (this is not a rhetorical
question, I'm genuinely curious).
It could also be argued that after all natural numbers can be handled
using signed integers, as long as in the transition from theoretical
analysis to practical analysis, the limitation of (2^31-1) is not that
different from the limitation of (2^32-1)

- more relevant, IMO: the main difference between signed and unsigned
types is that in the latter case all bits are digits, i.e. they
constitute a homogeneous set, which makes them specifically useful for
binary arithmetic (which justifies the difference in semantics, in my view).

On Monday, September 27, 2021 at 3:16:07 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes:
> [...]
> > Something new in C23 are attributes.
> > One of then is nodiscard :
> >
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
> >
> > "
> > EXAMPLE 2
> > [[nodiscard]] int important_func(void);
> > void call(void) {
> > int i = important_func();
> > }
> > No diagnostic for the call to important_func is encouraged despite the value of i not being used.
> > "
> > [[nodiscard("must check armed state")]]
> > bool arm_detonator(int);
> > void call(void) {
> > arm_detonator(3);
> > detonate();
> > }
> >
> > "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
> > clause is encouraged."
> >
> > This called my attention because the treatment is different for
> > int or _bool
> > I have no idea why.
> No, there's no difference in the treatment for int and _Bool.
>
> The two relevant examples are:
> [[nodiscard]] int important_func(void);
> void call(void) {
> int i = important_func();
> }
>
> No diagnostic for the call to important_func is encouraged despite
> the value of i not being used.
> and
> [[nodiscard("must check armed state")]]
> bool arm_detonator(int);
> void call(void) {
> arm_detonator(3);
> detonate();
> }
> A diagnostic for the call to arm_detonator using the string literal
> "must check armed state" from the attribute argument clause is
> encouraged.
> The difference isn't the types, it's the way the result is used. In the
> first example, the result of the function is used to initialize an
> object, so it's "used", even though that object's stored value is never
> used. In the second example, the result isn't assigned to anything.
> The point is that compilers aren't required to do data flow analysis;
> any immediate use of the result is enough to turn off the warning. (Of
> course compilers can warn about anything they like, and compilers
> commonly do warn about unused variables, but that warning isn't
> connected to the [[nodiscard]] attribute.)

hum.. right.
It is clear now thanks.

Although this can be ignored it looks a good documentation for the "function contract".

(The other topic about [static size] for arrays in that case I was expecting
more to be able to remove runtime checks and sizes.)

In this case it looks more like "nice to have" but not indispensable to change
the code style removing runtime checks for instance.

On Monday, September 27, 2021 at 6:20:51 PM UTC-3, Thiago Adams wrote:
> On Monday, September 27, 2021 at 3:16:07 PM UTC-3, Keith Thompson wrote:
> > Thiago Adams <thiago...@gmail.com> writes:
> > [...]
> > > Something new in C23 are attributes.
> > > One of then is nodiscard :
> > >
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
> > >
> > > "
> > > EXAMPLE 2
> > > [[nodiscard]] int important_func(void);
> > > void call(void) {
> > > int i = important_func();
> > > }
> > > No diagnostic for the call to important_func is encouraged despite the value of i not being used.
> > > "
> > > [[nodiscard("must check armed state")]]
> > > bool arm_detonator(int);
> > > void call(void) {
> > > arm_detonator(3);
> > > detonate();
> > > }
> > >
> > > "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
> > > clause is encouraged."
> > >
> > > This called my attention because the treatment is different for
> > > int or _bool
> > > I have no idea why.
> > No, there's no difference in the treatment for int and _Bool.
> >
> > The two relevant examples are:
> > [[nodiscard]] int important_func(void);
> > void call(void) {
> > int i = important_func();
> > }
> >
> > No diagnostic for the call to important_func is encouraged despite
> > the value of i not being used.
> > and
> > [[nodiscard("must check armed state")]]
> > bool arm_detonator(int);
> > void call(void) {
> > arm_detonator(3);
> > detonate();
> > }
> > A diagnostic for the call to arm_detonator using the string literal
> > "must check armed state" from the attribute argument clause is
> > encouraged.
> > The difference isn't the types, it's the way the result is used. In the
> > first example, the result of the function is used to initialize an
> > object, so it's "used", even though that object's stored value is never
> > used. In the second example, the result isn't assigned to anything.
> > The point is that compilers aren't required to do data flow analysis;
> > any immediate use of the result is enough to turn off the warning. (Of
> > course compilers can warn about anything they like, and compilers
> > commonly do warn about unused variables, but that warning isn't
> > connected to the [[nodiscard]] attribute.)
> hum.. right.
> It is clear now thanks.
>
> Although this can be ignored it looks a good documentation for the "function contract".
>
> (The other topic about [static size] for arrays in that case I was expecting
> more to be able to remove runtime checks and sizes.)
>
> In this case it looks more like "nice to have" but not indispensable to change
> the code style removing runtime checks for instance.

Microsoft compiler has the macro _Check_return_
https://docs.microsoft.com/en-us/cpp/code-quality/annotating-function-behavior?view=msvc-160

Another point about attributes is that they are optional for code generation, (at least standard ones)

"166)Standard attributes specified by this document can be parsed but ignored by
an implementation without changing the semantics of a correct program; the same is not true
for attributes not specified by this document."

but we cannot use an old compilers because the parsing will fail. so.. the macros will remain
or the code will be changed gradually.

On 9/27/21 9:45 PM, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> [...]
[...]
> The difference isn't the types, it's the way the result is used. In the
> first example, the result of the function is used to initialize an
> object, so it's "used", even though that object's stored value is never
> used. In the second example, the result isn't assigned to anything.
> The point is that compilers aren't required to do data flow analysis;
> any immediate use of the result is enough to turn off the warning. (Of
> course compilers can warn about anything they like, and compilers
> commonly do warn about unused variables, but that warning isn't
> connected to the [[nodiscard]] attribute.)
>

Thank you for explanation. I also found this link for nodiscard
attribute:

https://en.cppreference.com/w/c/language/attributes/nodiscard

I have a question about attributes too. Coder may use attributes
directly or he/she may include a header file (<attributes.h> for
instance) ?

Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 25.09.21 um 03:00 schrieb Branimir Maksimovic:
> > Look, bounds checking is costly, if done in run time, [?]
>
> Yes. But unlike Annex K, which is about runtime bounds checking, the
> features now discussed for C23 are about improving static bounds
> checking, i.e. compile-time bounds checking. Via array types, including
> VLA types, as function parameters. This could allow both improved
> diagnostics and optimization in the callee.
>
> AFAIR the main problem is that the syntax already has a meaning (an
> array currently just decays to a pointer). But maybe actual use is
> uncommen enough that it can still be changed.

I did not see current proposal in the standard. However, in the past
I have seen proposal for bounds checking in C. The whole idea was
that syntax should be acceptable to existing compiler and as long
as accesses are in bounds existing compiler should generate
correct code. Such proposals may break existing code, however
probably no more than type based alias analysis. And given
compile-time nature of checking conseqences of breakage should
be quite managable.

--
Waldek Hebisch

Manfred <noname@add.invalid> wrote:
> On 9/27/2021 6:38 PM, Ben Bacarisse wrote:
> > Manfred <noname@add.invalid> writes:
> >
> >> On 9/20/2021 7:55 PM, Bart wrote:
> >
> >>> Of course it makes perfect sense to have a pile of 4294967295 apples,
> >>> add another apple to the pile, and suddenly end up with 0 apples!
> >>> Meanwhile, someone could remove that extra apple from the pile of
> >>> -2147483648, to restore the original 2147483647, however that's too
> >>> late: the overflow police have already been, and will do so again
> >>> even when it becomes legal.
> >>>
> >>
> >> It's all about modeling a problem domain.
> >> In mathematics, /integer/ arithmetic (the one you use a.o. to add and
> >> subtract things) is /signed/ (for any serious work, at least). The
> >> tool that C offers to model this domain is signed integers - with the
> >> unavoidable limitations of limited size.
> >>
> >> Unsigned integers are the tool that C offers for /binary/
> >> arithmetic. In this context wrapping is one of the features that makes
> >> them useful.
> >
> > Some mathematics concerns the natural numbers. Unsigned integer types
> > would be an entirely natural (no pun intended) choice for these cases.
> >
>
> True, and in fact, while writing the post natural numbers came to mind
> as well; for example, in a simple counter unsigned int makes perfect sense.
>
> However, I was following up at Bart's post about what's the point of
> adding an apple to a pile of 4294967295 apples and end up with nothing,
> which is understandably disappointing, since stocking up that pile of
> apples probably took a considerable amount of work...
>
> A couple of considerations:
> - How common is the need to model math that is strictly about natural
> numbers compared to the need for integer math? (this is not a rhetorical
> question, I'm genuinely curious).

AFAICS typically in theoretical setting one considers integers
with possibly added assertion that they are nonnegative. But
there may be also assertion that numbers are bigger than 0,
or bigger than 1. And there are other popular assertions.
So IMHO need to specifically model nonnegative integers is
limited.

> It could also be argued that after all natural numbers can be handled
> using signed integers, as long as in the transition from theoretical
> analysis to practical analysis, the limitation of (2^31-1) is not that
> different from the limitation of (2^32-1)
>
> - more relevant, IMO: the main difference between signed and unsigned
> types is that in the latter case all bits are digits, i.e. they
> constitute a homogeneous set, which makes them specifically useful for
> binary arithmetic (which justifies the difference in semantics, in my view).

Actually, signed numbers works very well in base 3 (or other odd
bases). Difference compared to unsigned is that for signed numbers
it is natural to use signed digits. Signed digits means that
re-interpering string of digits as unsigend number changes value
in less regular way, so in new C3 (ternary C) language one
would have to decide if cast work by re-interpeting digist or
tries to preseve value.

--
Waldek Hebisch

On 2021-09-27, Manfred <noname@add.invalid> wrote:
> On 9/20/2021 7:55 PM, Bart wrote:
>> On 20/09/2021 17:17, David Brown wrote:
>>> On 20/09/2021 17:41, John Bode wrote:
>>
>>>> If signed integer representations other than two's complement will
>>>> no longer be supported, does this mean signed integer overflow can
>>>> have a well-defined behavior?  Or will it still be left undefined
>>>> to allow for optimizations?  Or could that be controlled with one
>>>> of these newfangled attribute thingies?
>>>
>>>
>>> No, signed integer overflow is still undefined behaviour - for which I
>>> am very glad.  Defining it is terrible, IMHO, since any definition you
>>> give will be the wrong answer.  Some would want it defined as wrapping
>>> ($DEITY knows why, since it is the silliest of all definitions despite
>>> being fairly efficient to implement), some would want it as an error or
>>> a trap, some would want saturation, some would want a NaN, some would
>>> want errno to be set.
>>>
>>> For those that think it makes sense to have a pile of 2147483647 apples,
>>> add another apple to the pile, and end up with -2147483648 apples, gcc
>>> still has the "-fwrapv" option.
>>
>> Of course it makes perfect sense to have a pile of 4294967295 apples,
>> add another apple to the pile, and suddenly end up with 0 apples!
>>
>> Meanwhile, someone could remove that extra apple from the pile of
>> -2147483648, to restore the original 2147483647, however that's too
>> late: the overflow police have already been, and will do so again even
>> when it becomes legal.
>>
>
> It's all about modeling a problem domain.
> In mathematics, /integer/ arithmetic (the one you use a.o. to add and
> subtract things) is /signed/ (for any serious work, at least).

Not true. That depends on Algebra you define, and is ok to define
operators only on positive set.

--

7-77-777
Evil Sinner!

scott@slp53.sl.home (Scott Lurndal) writes:

> Bart <bc@freeuk.com> writes:
>
>> [...]
>>
>> Try this program, where the number of applies is represented with
>> an 8-bit value:
>>
>> int8_t apples;
>>
>> apples = 127;
>> printf("Initial pile of apples: %d\n",apples);
>
> if (apples < CHAR_MAX) {
>
>> apples += 1;
>
> } else {
> panic("Logic error by the unqualified C programmer\n");
> }
>
> fixed it for you.

if (apples < SCHAR_MAX) {

Manfred <noname@add.invalid> writes:

> [...]

> - How common is the need to model math that is strictly about
> natural numbers compared to the need for integer math? (this is
> not a rhetorical question, I'm genuinely curious).

Combinatorics and number theory routinely concern themselves with
domains limited to the non-negative integers. The celebrated
prime number theorem, for example, counts primes less than a
given upper bound, but considers only non-negative numbers as
primes. Is -3 a prime? In a sense yes, but it's easier just to
avoid the question by admitting only non-negative integers as
candidates.

> It could also be argued that after all natural numbers can be
> handled using signed integers, as long as in the transition from
> theoretical analysis to practical analysis, the limitation of
> (2^31-1) is not that different from the limitation of (2^32-1)

Considering practical aspects of writing code, if the domain of
interest is confined to non-negative values, using an unsigned
type (for function parameters, etc) makes for an easier fit, as
otherwise input values would have to be tested for being negative,
and something done to handle the offending situation. If unsigned
types are used the problem doesn't come up.

Also, when working in code related to those theoretical domains,
I can say from first hand experience that we _always_ want that
last bit, no matter how wide the data type in question. An extra
bit means a larger range of applicability, and that's always
useful.

> - more relevant, IMO: the main difference between signed and
> unsigned types is that in the latter case all bits are digits,
> i.e. they constitute a homogeneous set, which makes them
> specifically useful for binary arithmetic (which justifies the
> difference in semantics, in my view).

Speaking for myself a more important difference is that signed
types have various pesky undefined and implementation-defined
behaviors, whereas unsigned types do not. In most cases it's
easier to reason about code that uses unsigned types if the range
of possible values is even remotely close to the limits of the
type in question. I routinely use unsigned types for variables
unless the variable in question must be able to hold a negative
value.

On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> [...]
>>>
>>> Try this program, where the number of applies is represented with
>>> an 8-bit value:
>>>
>>> int8_t apples;
>>>
>>> apples = 127;
>>> printf("Initial pile of apples: %d\n",apples);
>>
>> if (apples < CHAR_MAX) {
>>
>>> apples += 1;
>>
>> } else {
>> panic("Logic error by the unqualified C programmer\n");
>> }
>>
>> fixed it for you.
>
> if (apples < SCHAR_MAX) {
>
if (apples < sizeof(char)*CHAR_MAX) /** :P */

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Manfred <noname@add.invalid> writes:
>
>> [...]
>
>> - How common is the need to model math that is strictly about
>> natural numbers compared to the need for integer math? (this is
>> not a rhetorical question, I'm genuinely curious).
>
> Combinatorics and number theory routinely concern themselves with
> domains limited to the non-negative integers. The celebrated
> prime number theorem, for example, counts primes less than a
> given upper bound, but considers only non-negative numbers as
> primes. Is -3 a prime?

Please take a look at this video carefully:
https://youtu.be/094y1Z2wpJg

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

William Ahern <william@25thandClement.com> writes:

> [...]
> IME [a very important pre-processor capability] is the ability to
> use the defined operator in macros.

I share your sense that this would be a useful capability, including
the lazy evaluation aspect. However there are (or at least may be)
subtle interactions that need to be worked out. For example,

#define foo(x) INT_MIN < -INT_MAX || defined x

or

#define bas(x) defined x##_a || defined x##_b

would very likely need new wording in how macro expansion works so
that these and other unusual cases would be unambiguously defined.
Not necessarily an easy job.

Bottom line, if you think some capability in this direction is
important to add to the C standard, write a proposal that covers
what changes are needed, including all the oddball and corner cases,
and submit it to the ISO C committee. These things don't happen
unless they have a champion who has gone through much of the
preliminary effort to get them incorporated into the C standard.

On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> William Ahern <william@25thandClement.com> writes:
>
>> [...]
>> IME [a very important pre-processor capability] is the ability to
>> use the defined operator in macros.
>
> I share your sense that this would be a useful capability, including
> the lazy evaluation aspect. However there are (or at least may be)
> subtle interactions that need to be worked out. For example,
>
> #define foo(x) INT_MIN < -INT_MAX || defined x
>
what's wrong with:
#define x 5
#include <limits.h>
#if defined(x)
#define foo(x) INT_MIN < -INT_MAX
#endif
#include <stdio.h>
int main(void) {
if(foo(FIVE))printf("%d\n",foo(3));
}

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Manfred <noname@add.invalid> writes:
>>
>>> [...]
>>
>>> - How common is the need to model math that is strictly about
>>> natural numbers compared to the need for integer math? (this is
>>> not a rhetorical question, I'm genuinely curious).
>>
>> Combinatorics and number theory routinely concern themselves with
>> domains limited to the non-negative integers. The celebrated
>> prime number theorem, for example, counts primes less than a
>> given upper bound, but considers only non-negative numbers as
>> primes. Is -3 a prime?
>
> Please take a look at this video carefully:
> https://youtu.be/094y1Z2wpJg

Why?

(It's about the Collatz Conjecture, and it's more than 20 minutes long.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-02, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Manfred <noname@add.invalid> writes:
>>>
>>>> [...]
>>>
>>>> - How common is the need to model math that is strictly about
>>>> natural numbers compared to the need for integer math? (this is
>>>> not a rhetorical question, I'm genuinely curious).
>>>
>>> Combinatorics and number theory routinely concern themselves with
>>> domains limited to the non-negative integers. The celebrated
>>> prime number theorem, for example, counts primes less than a
>>> given upper bound, but considers only non-negative numbers as
>>> primes. Is -3 a prime?
>>
>> Please take a look at this video carefully:
>> https://youtu.be/094y1Z2wpJg
>
> Why?
>
> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>
So do you have *explanation*?
Why do you ask about negative primes?

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
[...]
>>> Please take a look at this video carefully:
>>> https://youtu.be/094y1Z2wpJg
>>
>> Why?
>>
>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>
> So do you have *explanation*?

For what?

> Why do you ask about negative primes?

I didn't.

Is there anything in the video that's relevant either to this newsgroup
or to this thread? If so, what?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

* John Bode:

> it could simply just not name them:
>
> void bletch( int *, char *, double f )
> {
> // do something with f
> }
>
> and avoid that altogether.
>
> Shitcanning old-style function definitions is long overdue - yes, I'm
> sure this will break a non-trivial amount of legacy code, but dammit,
> a lot of that code *needs* to be broken so it can be properly updated.

The change is supposed to be compatible with both old-style function
definitions and implicit ints. There could be a syntactic ambiguity,
but in this context, at least GCC today treats an identifier that has
a type of the same name in scope as a type, not as a parameter name
(which could either be int implicitly, or assigned a different type
later). So no currently accepted programs should change meaning.

I'm not saying that implicit ints (or implicit function declarations)
or old-style function definitions are a good thing. But there isn't
much of a compatibility concern here, I think.

On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> [...]
>>>> Please take a look at this video carefully:
>>>> https://youtu.be/094y1Z2wpJg
>>>
>>> Why?
>>>
>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>
>> So do you have *explanation*?
>
> For what?
>
>> Why do you ask about negative primes?
>
> I didn't.
>
> Is there anything in the video that's relevant either to this newsgroup
> or to this thread? If so, what?
>
Sorry, that was Ttim Rensch i replied, you just replied
on something wasn't you asked for :P

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

Le 03/10/2021 à 09:43, Florian Weimer a écrit :
> * John Bode:
>
>> it could simply just not name them:
>>
>> void bletch( int *, char *, double f )
>> {
>> // do something with f
>> }
>>
>> and avoid that altogether.
>>
>> Shitcanning old-style function definitions is long overdue - yes, I'm
>> sure this will break a non-trivial amount of legacy code, but dammit,
>> a lot of that code *needs* to be broken so it can be properly updated.
>
> The change is supposed to be compatible with both old-style function
> definitions and implicit ints. There could be a syntactic ambiguity,
> but in this context, at least GCC today treats an identifier that has
> a type of the same name in scope as a type, not as a parameter name
> (which could either be int implicitly, or assigned a different type
> later). So no currently accepted programs should change meaning.
>
> I'm not saying that implicit ints (or implicit function declarations)
> or old-style function definitions are a good thing. But there isn't
> much of a compatibility concern here, I think.

And anyway... speaking of GCC, it still supports C89 using the -std
option, so breaking old code is not really an issue. GCC might not keep
support for very old standard revisions forever, but by the time C23 is
the minimal revision supported, you'll have had ample time to migrate.
Probably same thing with most other C compilers out there.

Just because there is a new revision of the standard out doesn't mean
you *have* to comply with it. Nothing wrong with sticking to older
revisions if a given code base requires it. Sure at some point, very old
revisions will probably stop being supported, but I doubt it's going to
happen anytime soon. Just a thought.

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> [...]
>>>>> Please take a look at this video carefully:
>>>>> https://youtu.be/094y1Z2wpJg
>>>>
>>>> Why?
>>>>
>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>>
>>> So do you have *explanation*?
>>
>> For what?
>>
>>> Why do you ask about negative primes?
>>
>> I didn't.
>>
>> Is there anything in the video that's relevant either to this newsgroup
>> or to this thread? If so, what?
>>
> Sorry, that was Ttim Rensch i replied, you just replied
> on something wasn't you asked for :P

So you posted a link to a 20-minute video with no explanation, and
you're still unwilling to explain how or whether it's relevant.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Florian Weimer <fw@deneb.enyo.de> writes:
> * John Bode:
>
>> it could simply just not name them:
>>
>> void bletch( int *, char *, double f )
>> {
>> // do something with f
>> }
>>
>> and avoid that altogether.
>>
>> Shitcanning old-style function definitions is long overdue - yes, I'm
>> sure this will break a non-trivial amount of legacy code, but dammit,
>> a lot of that code *needs* to be broken so it can be properly updated.
>
> The change is supposed to be compatible with both old-style function
> definitions and implicit ints. There could be a syntactic ambiguity,
> but in this context, at least GCC today treats an identifier that has
> a type of the same name in scope as a type, not as a parameter name
> (which could either be int implicitly, or assigned a different type
> later). So no currently accepted programs should change meaning.

Implicit int has not existed in the C language since the 1999 standard,
and all code that depends on it has been invalid since then.

Treating a possibly ambiguous identifier as a type name isn't specific
to GCC. It's a language rule. See N1570 6.7.6.3p11.

The N2596 draft of C23 is not compatible with old-style function
definitions. It does retain old-style function *declarations* (and
marks them as obsolescent).

This:

int main(argc, argv)
int argc;
char *argv[];
{
}

is valid in all versions of C up to and including C17, but is invalid in
the proposed C23.

> I'm not saying that implicit ints (or implicit function declarations)
> or old-style function definitions are a good thing. But there isn't
> much of a compatibility concern here, I think.

There is.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>> On 2021-10-03, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>>> On 2021-10-02, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
>>> [...]
>>>>>> Please take a look at this video carefully:
>>>>>> https://youtu.be/094y1Z2wpJg
>>>>>
>>>>> Why?
>>>>>
>>>>> (It's about the Collatz Conjecture, and it's more than 20 minutes long.)
>>>>>
>>>> So do you have *explanation*?
>>>
>>> For what?
>>>
>>>> Why do you ask about negative primes?
>>>
>>> I didn't.
>>>
>>> Is there anything in the video that's relevant either to this newsgroup
>>> or to this thread? If so, what?
>>>
>> Sorry, that was Ttim Rensch i replied, you just replied
>> on something wasn't you asked for :P
>
> So you posted a link to a 20-minute video with no explanation, and
> you're still unwilling to explain how or whether it's relevant.
>
It shows two things: math is connected to reality,
and second, explains why strong AI is impossible :P

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp