Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #162767 > unrolled thread

C23 (C2x) changes

Back to article view | Back to comp.lang.c

Contents

  C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-20 10:54 +0430
    Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 09:35 +0200
      Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-21 11:01 +0430
    Re: C23 (C2x) changes John Bode <jfbode1029@gmail.com> - 2021-09-20 10:41 -0500
      Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 18:17 +0200
        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 18:55 +0100
          Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 18:21 +0000
          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 21:39 +0200
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 21:07 +0100
              Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 22:59 +0200
                Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 22:29 +0100
                  Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:43 -0700
                  Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-21 17:56 +0200
                    Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-21 18:05 +0100
                      Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:42 -0700
                      Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 11:37 +0200
                        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 11:55 +0100
                          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 14:21 +0200
                            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 13:58 +0100
                    Re: C23 (C2x) changes Ian Pilcher <arequipeno@gmail.com> - 2021-09-22 12:02 -0500
                      Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-22 17:19 +0000
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 23:05 +0100
              Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 22:47 +0000
                Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-09-20 22:58 +0000
                Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 07:16 -0700
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:15 +0000
              Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:45 -0700
          Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 17:15 +0200
            Re: C23 (C2x) changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-27 17:38 +0100
              Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 23:18 +0200
                Re: C23 (C2x) changes antispam@math.uni.wroc.pl - 2021-09-28 13:53 +0000
                Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:07 -0700
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:18 +0000
                    Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 15:04 -0700
                      Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 01:58 +0000
                        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 22:06 -0700
                          Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 10:43 +0000
                            Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:30 -0700
                              Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 05:04 +0000
                                Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 23:24 -0700
                                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 06:54 +0000
                                Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-04 09:58 +0200
                                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 15:52 +0000
                                    Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-04 10:45 -0700
                                      Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 20:30 +0000
                                      Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 03:57 -0700
                                        Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 12:27 +0000
            Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 03:38 +0000
        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 11:35 +0100
          Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 18:27 +0000
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 20:08 +0100
            Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 19:20 +0000
              Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 21:50 +0100
      Re: C23 (C2x) changes Florian Weimer <fw@deneb.enyo.de> - 2021-10-03 09:43 +0200
        Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-03 18:53 +0200
        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:55 -0700
    Re: C23 (C2x) changes William Ahern <william@25thandClement.com> - 2021-09-21 22:57 -0700
      Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:55 -0700
        Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 16:36 +0000
    Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-22 20:27 +0200
      Re: C23 (C2x) changes Philipp Klaus Krause <pkk@spth.de> - 2021-09-22 22:25 +0200
        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 14:05 -0700
          Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 23:24 +0100
            Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-22 18:49 -0700
          Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-23 18:47 +0200
    Static bounds checking (was Re: C23 (C2x) changes) William Ahern <william@25thandClement.com> - 2021-09-23 21:11 -0700
      Re: Static bounds checking (was Re: C23 (C2x) changes) David Brown <david.brown@hesbynett.no> - 2021-09-24 08:51 +0200
        Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 09:30 +0200
      Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:52 +0000
        Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 12:32 +0200
          Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 10:49 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 14:46 +0200
        Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:14 +0200
          Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 01:00 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-25 07:44 +0200
              Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:28 +0000
              Re: Static bounds checking (was Re: C23 (C2x) changes) antispam@math.uni.wroc.pl - 2021-09-28 10:56 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 09:48 +0200
              Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:30 +0000
                Re: Static bounds checking (was Re: C23 (C2x) changes) Kaz Kylheku <480-992-1380@kylheku.com> - 2021-09-25 20:49 +0000
                  Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-26 00:04 +0000
                Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-26 06:56 +0200
    Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 10:15 -0700
      Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-27 11:15 -0700
        Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-27 22:11 +0200
        Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:20 -0700
          Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:31 -0700
        Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-28 10:43 +0330
    Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 04:01 -0700
      Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-06 04:42 -0700
        Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:04 -0700
          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-29 16:34 +0200
      Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-06 19:07 +0200
        Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 11:06 +0200
          Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-07 19:31 +0200
            Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 22:14 +0200
              Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:18 -0700
                Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:21 -0700
        Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:01 -0700
      Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-15 12:59 +0200
        Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-15 16:50 +0000
          Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 07:51 +0200
            Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-16 11:50 -0700
              Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 21:28 +0200
                Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-17 17:18 +0000
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:00 +0200
                    Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-17 19:17 +0100
                      Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 06:49 +0200
                        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-18 11:23 +0100
                          Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 14:09 +0200
                    Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:07 +0000
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
            Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-16 21:28 +0200
              Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 06:04 +0200
                Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-10-17 19:35 +0200
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:01 +0200
                    Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-17 14:15 -0700
                Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:15 +0200

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#162974

On 2021-10-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
> So it's not relevant to this thread or to this newsgroup.
>
> This newsgroup discusses the C programming language.  If you want to
> discuss something unrelated to that, please find another place to do so.
>
It is relevant, as qustion was if prime numbers can be negative.
I haven't asked question, I just gave link that discuss prime
numbers and whether they can be considered negative...
iThis all started with question of whether unsigned integers
can be considered mathematical concept. Unswer is yes.
Natural set + zero. 
-- 

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

[toc] | [prev] | [next] | [standalone]

#162975

On 04/10/2021 07:04, Branimir Maksimovic wrote:
> 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
> 

No, it does not show either of these two things.  Have you actually
/watched/ it yourself?

Neither of these two points has anything to do with C.  Nothing in the
video has anything to do with C.  It is completely unrelated to anything
in this group, except for the one thread that was precisely about C code
for implementing the mathematics in the Collatz Conjecture.

It is an interesting and worthwhile video, IMHO, and I had watched it
previously.  But this is a newsgroup for C, not a group for interesting
and worthwhile videos (even imagining that there could be a consensus on
what is interesting in a video).

[toc] | [prev] | [next] | [standalone]

#162980

On 2021-10-04, David Brown <david.brown@hesbynett.no> wrote:
> On 04/10/2021 07:04, Branimir Maksimovic wrote:
>> 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
>> 
>
> No, it does not show either of these two things.  Have you actually /watched/
> it yourself?
>
> Neither of these two points has anything to do with C.  Nothing in the video
> has anything to do with C.  It is completely unrelated to anything in this
> group, except for the one thread that was precisely about C code for
> implementing the mathematics in the Collatz Conjecture.
>
> It is an interesting and worthwhile video, IMHO, and I had watched it
> previously.  But this is a newsgroup for C, not a group for interesting and
> worthwhile videos (even imagining that there could be a consensus on what is
> interesting in a video).
>
>
Look when you speaking about numbers and relation of C types to numbers
it is relevant...

-- 

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

[toc] | [prev] | [next] | [standalone]

#162986

Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
[...]
> Look when you speaking about numbers and relation of C types to numbers
> it is relevant...

You replied to a post that discussed signed and unsigned types.
You posted a link to a Youtube video and said nothing else about it.
You said nothing about C, and as far as I can tell the video said
nothing about C.

If you're going to post an Youtube or similar link, *at least* say
something about it.  Nobody wants to spend 20 minutes watching something
just in case there's something 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 */

[toc] | [prev] | [next] | [standalone]

#162994

On 2021-10-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> [...]
>> Look when you speaking about numbers and relation of C types to numbers
>> it is relevant...
>
> You replied to a post that discussed signed and unsigned types.
> You posted a link to a Youtube video and said nothing else about it.
> You said nothing about C, and as far as I can tell the video said
> nothing about C.
>
> If you're going to post an Youtube or similar link, *at least* say
> something about it.  Nobody wants to spend 20 minutes watching something
> just in case there's something relevant.
>
Thanks, I'll remember that, and correct my behavior.


-- 

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

[toc] | [prev] | [next] | [standalone]

#163014

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
> [...]
>
>> Look when you speaking about numbers and relation of C types to numbers
>> it is relevant...
>
> You replied to a post that discussed signed and unsigned types.
> You posted a link to a Youtube video and said nothing else about it.
> You said nothing about C, and as far as I can tell the video said
> nothing about C.
>
> If you're going to post an Youtube or similar link, *at least* say
> something about it.  Nobody wants to spend 20 minutes watching something
> just in case there's something relevant.

I have adopted a policy of not reading postings from Branimir
Maksimovic.  This recent series of exchanges illustrates why.

[toc] | [prev] | [next] | [standalone]

#163019

On 2021-10-06, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
> I have adopted a policy of not reading postings from Branimir
> Maksimovic.  This recent series of exchanges illustrates why.
Well, I have added you to my Score file in Head as Well....

-- 

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

[toc] | [prev] | [next] | [standalone]

#162863

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!

[toc] | [prev] | [next] | [standalone]

#163093

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.

Here's an example where signed wrapping came in useful. I wanted to do 
this in a language (not C nor one of mine), where I knew integer 
literals had int64 type, and need the largest value it could represent.

    writeln(2**63-1)

It failed because it trapped integer overflow. So I couldn't do it.

If I tried it mine (I'd use C but it doesn't have a pow() op for integers):

    println 2**63-1

it gave the expected answer. This briefly wraps one way (to int64.min), 
then wraps the other way (to int64.max) to get the right answer.

Exactly the same thing that happens with unsigned:

   println 2**64-1

This one wraps to 0 (uint64.min) then other way to uint.max. It is 
useful behaviour for uint64; it is useful for int64.

But in both cases, you need to be aware of those temporary out-of-range 
excursions, and not use the intermediate results as though they 
represented natural arithmetic.

[toc] | [prev] | [next] | [standalone]

#163097

On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
[snip]
> If I tried it mine (I'd use C but it doesn't have a pow() op for
> integers):

That's a lame excuse, if I've ever heard one

> 
>     println 2**63-1

You /don't need/ "pow() for integers" to express 2^63 - 1 in C.

You could either hand expand 2^63 -1 into an integer, or, given an 
integral type of 64 bits or larger,  you simply use
  (2ul<<63) - 1

as in
  printf("%ul\n",(2ul<<63)-1);

[snip]
-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#163098

On 15/10/2021 19:27, Lew Pitcher wrote:
> On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
> [snip]
>> If I tried it mine (I'd use C but it doesn't have a pow() op for
>> integers):
> 
> That's a lame excuse, if I've ever heard one
> 
>>
>>      println 2**63-1
> 
> You /don't need/ "pow() for integers" to express 2^63 - 1 in C.

Yes, there are any number of ways of avoiding doing the work, namely 
/working out/ 2**63-1 using signed integers and exponentiation or at 
least multiplication.

I wanted the language to do it.

> You could either hand expand 2^63 -1 into an integer, or, given an
> integral type of 64 bits or larger,  you simply use
>    (2ul<<63) - 1

Now try that method for a ternary computer, using 39 bits (max 
representable within int64).

[toc] | [prev] | [next] | [standalone]

#163099

On Fri, 15 Oct 2021 18:27:59 +0000, Lew Pitcher wrote:

> On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
> [snip]
>> If I tried it mine (I'd use C but it doesn't have a pow() op for
>> integers):
> 
> That's a lame excuse, if I've ever heard one
> 
> 
>>     println 2**63-1
> 
> You /don't need/ "pow() for integers" to express 2^63 - 1 in C.
> 
> You could either hand expand 2^63 -1 into an integer, or, given an
> integral type of 64 bits or larger,  you simply use
>   (2ul<<63) - 1

Yah, I know. A thinko
I meant
  (1ul<<63) - 1

> 
> as in
>   printf("%ul\n",(2ul<<63)-1);

    printf("%ul\n",(1ul<<63)-1);

> [snip]




-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#163100

On 15/10/2021 20:20, Lew Pitcher wrote:
> On Fri, 15 Oct 2021 18:27:59 +0000, Lew Pitcher wrote:
> 
>> On Fri, 15 Oct 2021 11:35:19 +0100, Bart wrote:
>> [snip]
>>> If I tried it mine (I'd use C but it doesn't have a pow() op for
>>> integers):
>>
>> That's a lame excuse, if I've ever heard one
>>
>>
>>>      println 2**63-1
>>
>> You /don't need/ "pow() for integers" to express 2^63 - 1 in C.
>>
>> You could either hand expand 2^63 -1 into an integer, or, given an
>> integral type of 64 bits or larger,  you simply use
>>    (2ul<<63) - 1
> 
> Yah, I know. A thinko
> I meant
>    (1ul<<63) - 1
> 

I was going to say that I don't like using shifts because I tend to get 
it wrong.

And actually, this is still not right: it will only work when 'long' 
happens to be 64 bits. It's likely to be 32 bits on Windows and 32-bit OSes.

1ULL is a better bet (together with a %lld format).


>> as in
>>    printf("%ul\n",(2ul<<63)-1);
> 
>      printf("%ul\n",(1ul<<63)-1);
> 
>> [snip]

[toc] | [prev] | [next] | [standalone]

#162958

* 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.

[toc] | [prev] | [next] | [standalone]

#162963

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.

[toc] | [prev] | [next] | [standalone]

#162969

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 */

[toc] | [prev] | [next] | [standalone]

#162811

Mehdi Amini <atorrses@gmail.com> 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.

The addition of #elifdef and #elifndef is just unnecessary complexity. Some
people seem to dislike using defined() because there are some relatively
modern coding style guides that prohibit use of defined or even any other
preprocessor operators; instead they limit preprocessor usage to simple
directives like #include and #ifdef. These style guides have created a
narrative that complex use of the preprocessor should be categorically
avoided. There's more than a little irony in adding preprocessor complexity
at the behest of folks who fundamentally abhor the preprocessor.

I do like the addition of __has_include for improving the ability to perform
feature checking directly from the preprocessor. But IME at least as
important as __has_include for preprocessor-based feature checking, if not
more important, is the ability to use the defined operator in macros. For
example,

  #ifndef HAVE_STRUCT_STAT_ST_ATIMESPEC
  #define HAVE_STRUCT_STAT_ST_ATIMESPEC (__APPLE__ || defined st_atimespec || defined st_atimensec)
  #endif

Using HAVE_STRUCT_STAT_ST_ATIMESPEC in another preprocess conditional isn't
well-defined C, although it's widely supported (Visual Studio being a major
outlier). Instead you have to do

  #if  __APPLE__ || defined st_atimespec || defined st_atimensec
  #define HAVE_STRUCT_STAT_ST_ATIMESPEC 1
  #else
  #define HAVE_STRUCT_STAT_ST_ATIMESPEC 0
  #endif  

which nearly doubles the lines of code needed for a simple feature check.
(NOTE: Unlike autoconf, I conditionally define HAVE macros in my code so
that the build engineer can choose to override the feature detection by
predefining the macro value.)

More importantly, the former evaluates lazily at point of use, while the
latter evaluates immediately, requiring the compilation unit to have already
#include'd <sys/stat.h>. That makes it very difficult to put a bunch of
generic preprocessor checks in a separate header library as you either need
to rely on the user including the correct headers or the feature check
header must include them unconditionally, polluting the namespace and
possibly changing semantics.

I maintain a project where I version some pure preprocessor-based feature
checks for common Unix platforms:

  https://github.com/wahern/autoguess

I once tried refactoring everything to standard C after clang default
enabled its -Wexpansion-to-defined warning, but the refactor proved too
unwieldly and, more importantly, ultimately unworkable given the need to
implicitly include problematic headers like <pthread.h> in the absence of
lazy evaluation. (There are some implicit #include's, but __has_include
would have helped rid some of them.)

Even better than well-defined defined operator expansions would be the
ability to test the presence of function definitions, type definitions, and
aggregate members, but that's probably a bridge too far.

[toc] | [prev] | [next] | [standalone]

#162941

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.

[toc] | [prev] | [next] | [standalone]

#162942

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

[toc] | [prev] | [next] | [standalone]

#162820

Le 20/09/2021 à 08:24, Mehdi Amini a écrit :
> 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 ?

Dunno - not that impressive. Don't get me wrong, I prefer the 
conservative approach of the C std committee to the approach of the C++
one, which yields monsters.

But this looks like relatively minor improvements to me.

What I would like to see in a new C revision:
- Modules;
- Tagged blocks/tagged loop constructs.

The tagged loop thing could look like this:

outer_loop: for (i = 0; i < n; i++)
{
	for (j = 0; j < i; j++)
	{
		...
		if (...)
			break outer_loop;
	}
}

That would be more elegant and easier to statically analyze than goto's. 
The syntax could be different, it's just to show the point. In 
particular, to avoid confusion with goto labels, it could instead be 
something like:

for outer_loop (i = 0; i < n; i++)
...

As to modules, that could be taken from C++20(?) modules, although I 
think those are not that great, but that's a start.

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web