• Re: Initialization Of Static Pointer Variables

    From Lane W@3:633/10 to All on Wed Sep 9 07:54:38 2026
    Keith Thompson wrote:
    presentation of a null pointer. This:

    #include <stdio.h>
    int main(void) {
    static void *ptr;
    if (ptr != NULL) puts("OOPS");
    if (ptr != 0) puts("OOPS");
    }

    must not print "OOPS".


    What you've done here is not good. I can't imagine you came away from
    this not feeling soiled. Here's a card for a local church where you can confess what you wrote.

    GracePoint
    Community Church
    You Are Welcome Here!
    JOIN US THIS SUNDAY

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Johann "Myrkraverk" Oskarsson@3:633/10 to All on Wed Sep 9 22:39:07 2026
    On 9/9/2026 9:54 PM, Lane W wrote:
    Keith Thompson wrote:
    presentation of a null pointer.ÿ This:

    #include <stdio.h>
    int main(void) {
    ÿÿÿÿ static void *ptr;
    ÿÿÿÿ if (ptr != NULL) puts("OOPS");
    ÿÿÿÿ if (ptr != 0)ÿÿÿ puts("OOPS");
    }

    must not print "OOPS".


    What you've done here is not good. I can't imagine you came away from
    this not feeling soiled. Here's a card for a local church where you can confess what you wrote.

    ÿ GracePoint
    Community Church
    You Are Welcome Here!
    JOIN US THIS SUNDAY

    I'm more concerned that if this is compiled on a machine where ptr fits
    in a register, and that register happens to contain zero by chance, what happens to Keith's sense of correctness?

    Did Keith manage to make a program that is stochastically wrong, like
    an L.L.M?
    --
    Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
    I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From James Kuyper@3:633/10 to All on Wed Sep 9 10:53:51 2026
    On 2026-09-09 09:54, Lane W wrote:
    Keith Thompson wrote:
    presentation of a null pointer. This:

    #include <stdio.h>
    int main(void) {
    static void *ptr;
    if (ptr != NULL) puts("OOPS");
    if (ptr != 0) puts("OOPS");
    }

    must not print "OOPS".


    What you've done here is not good. I can't imagine you came away from
    this not feeling soiled. Here's a card for a local church where you can confess what you wrote.

    What is your objection to what he wrote? What he said is guaranteed to
    be true for any conforming implementation of C.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Richard Tobin@3:633/10 to All on Wed Sep 9 18:52:30 2026
    In article <gceoS.124510$NMu2.16715@fx15.ams4>,
    Johann \"Myrkraverk\" Oskarsson <johann@myrkraverk.invalid> wrote:

    ÿÿÿÿ static void *ptr;
    ÿÿÿÿ if (ptr != NULL) puts("OOPS");
    ÿÿÿÿ if (ptr != 0)ÿÿÿ puts("OOPS");

    I'm more concerned that if this is compiled on a machine where ptr fits
    in a register, and that register happens to contain zero by chance, what >happens to Keith's sense of correctness?

    If the compiler uses a register for a static variable, it must ensure
    that the register is initialized to the correct value.

    -- Richard

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Keith Thompson@3:633/10 to All on Wed Sep 9 16:34:47 2026
    James Kuyper <jameskuyper@alumni.caltech.edu> writes:
    On 2026-09-09 09:54, Lane W wrote:
    Keith Thompson wrote:
    presentation of a null pointer. This:

    #include <stdio.h>
    int main(void) {
    static void *ptr;
    if (ptr != NULL) puts("OOPS");
    if (ptr != 0) puts("OOPS");
    }

    must not print "OOPS".


    What you've done here is not good. I can't imagine you came away from
    this not feeling soiled. Here's a card for a local church where you can
    confess what you wrote.

    What is your objection to what he wrote? What he said is guaranteed to
    be true for any conforming implementation of C.

    I doubt that he has any real objection to what I wrote. This appears
    to be a personal attack, a childish overreaction to my criticisms
    of some code he posted recently.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From dave_thompson_2@3:633/10 to All on Tue Sep 15 21:22:22 2026
    On Thu, 27 Aug 2026 13:39:24 -0000 (UTC), antispam@fricas.org (Waldek
    Hebisch) wrote:

    bart <bc@freeuk.com> wrote:
    ..., So what sorts of things need a 64-bit [int] range?
    ...
    3) Cryptography. 32-bit cryptographic keys are deemed inadequate
    for most purposes. So, minimal reasonably safe cryptography needs
    64-bits. And with spead of radio controlled devices (like garage
    doors) there is increasing need for cryptography.

    Not keys. 64-bit key was _barely_ adequate back when DES was
    standardized, and has been unacceptable since the 1990s. (32-bit was
    _never_ safe; during the 'crypto wars' period in the 1980s and 1990s,
    when US and Europe tried to prevent spread of decent crypto,
    the 'export' options in e.g. SSL used 40-bit _because_ "we can break
    that".) Since 2010 at latest 128-bit is minimum,and now that people
    are worried that quantum breaking will become practical, 256-bit is
    more and more required.

    But crypto does NOT operate on the whole key as a unit. Most
    algorithms operate on either 32-bit or 64-bit chunks of data and the
    same or sometimes less of the key.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Waldek Hebisch@3:633/10 to All on Wed Sep 16 03:10:35 2026
    dave_thompson_2@comcast.net wrote:
    On Thu, 27 Aug 2026 13:39:24 -0000 (UTC), antispam@fricas.org (Waldek Hebisch) wrote:

    bart <bc@freeuk.com> wrote:
    ..., So what sorts of things need a 64-bit [int] range?
    ...
    3) Cryptography. 32-bit cryptographic keys are deemed inadequate
    for most purposes. So, minimal reasonably safe cryptography needs
    64-bits. And with spead of radio controlled devices (like garage
    doors) there is increasing need for cryptography.

    Not keys. 64-bit key was _barely_ adequate back when DES was
    standardized, and has been unacceptable since the 1990s.

    For encrypting data, sure. But that is not the only use of
    cryptography. Popular door opening systems use 32-bit tokens.
    This is inadequate and AFAIK this system was broken. AFAICS
    64-bit system should be resonable safe (at least before time
    when fast quantum computers get popular).

    But crypto does NOT operate on the whole key as a unit. Most
    algorithms operate on either 32-bit or 64-bit chunks of data and the
    same or sometimes less of the key.

    But 64-bit chunks are likely to be most convenient.

    --
    Waldek Hebisch

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Brown@3:633/10 to All on Wed Sep 16 09:24:59 2026
    On 16/09/2026 03:22, dave_thompson_2@comcast.net wrote:
    On Thu, 27 Aug 2026 13:39:24 -0000 (UTC), antispam@fricas.org (Waldek Hebisch) wrote:

    bart <bc@freeuk.com> wrote:
    ..., So what sorts of things need a 64-bit [int] range?
    ...
    3) Cryptography. 32-bit cryptographic keys are deemed inadequate
    for most purposes. So, minimal reasonably safe cryptography needs
    64-bits. And with spead of radio controlled devices (like garage
    doors) there is increasing need for cryptography.

    Not keys. 64-bit key was _barely_ adequate back when DES was
    standardized, and has been unacceptable since the 1990s. (32-bit was
    _never_ safe; during the 'crypto wars' period in the 1980s and 1990s,
    when US and Europe tried to prevent spread of decent crypto,
    the 'export' options in e.g. SSL used 40-bit _because_ "we can break
    that".) Since 2010 at latest 128-bit is minimum,and now that people
    are worried that quantum breaking will become practical, 256-bit is
    more and more required.


    There is a vast amount of stuff related to cryptography or security for
    which 32-bit is entirely fine. There are other things for which
    8096-bit is a better choice. It all depends on what you are trying to protect, how attacks can work, and how much real entropy there is in the
    key (rather than the key length).

    Remember, access to your bank account is secured by a number that is not
    even 14 bits - it's a 4-digit PIN. And that is secure for its purpose.


    But crypto does NOT operate on the whole key as a unit. Most
    algorithms operate on either 32-bit or 64-bit chunks of data and the
    same or sometimes less of the key.

    A lot of popular cryptographic algorithms are optimised to work with
    64-bit chunks, so they are convenient for efficient implementation. But
    the algorithms can work happily (albeit slowly) on 8-bit computers.


    People may be worried about quantum computers breaking current
    encryption systems, but they should not be - there is no realistic
    pathway towards quantum computers being physically or economically
    viable for the task.

    As the great philosopher Dara ? Briain said, "Zombies are at an all-time
    low level, but the fear of zombies could be incredibly high. It doesn't
    mean we have to have government policies to deal with the fear of zombies."

    Fear of quantum computers breaking encryption may be high, but it's not something we should actually be worrying about.



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From bart@3:633/10 to All on Wed Sep 16 10:03:28 2026
    On 16/09/2026 08:24, David Brown wrote:
    On 16/09/2026 03:22, dave_thompson_2@comcast.net wrote:
    On Thu, 27 Aug 2026 13:39:24 -0000 (UTC), antispam@fricas.org (Waldek
    Hebisch) wrote:

    bart <bc@freeuk.com> wrote:
    ..., So what sorts of things need a 64-bit [int] range?
    ...
    3) Cryptography.ÿ 32-bit cryptographic keys are deemed inadequate
    for most purposes.ÿ So, minimal reasonably safe cryptography needs
    64-bits.ÿ And with spead of radio controlled devices (like garage
    doors) there is increasing need for cryptography.

    Not keys. 64-bit key was _barely_ adequate back when DES was
    standardized, and has been unacceptable since the 1990s. (32-bit was
    _never_ safe; during the 'crypto wars' period in the 1980s and 1990s,
    when US and Europe tried to prevent spread of decent crypto,
    the 'export' options in e.g. SSL used 40-bit _because_ "we can break
    that".) Since 2010 at latest 128-bit is minimum,and now that people
    are worried that quantum breaking will become practical, 256-bit is
    more and more required.


    There is a vast amount of stuff related to cryptography or security for which 32-bit is entirely fine.ÿ There are other things for which 8096-
    bit is a better choice.ÿ It all depends on what you are trying to
    protect, how attacks can work, and how much real entropy there is in the
    key (rather than the key length).

    Remember, access to your bank account is secured by a number that is not even 14 bits - it's a 4-digit PIN.ÿ And that is secure for its purpose.


    But crypto does NOT operate on the whole key as a unit. Most
    algorithms operate on either 32-bit or 64-bit chunks of data and the
    same or sometimes less of the key.

    A lot of popular cryptographic algorithms are optimised to work with 64-
    bit chunks, so they are convenient for efficient implementation.ÿ But
    the algorithms can work happily (albeit slowly) on 8-bit computers.


    People may be worried about quantum computers breaking current
    encryption systems, but they should not be - there is no realistic
    pathway towards quantum computers being physically or economically
    viable for the task.

    As the great philosopher Dara ? Briain said, "Zombies are at an all-time
    low level, but the fear of zombies could be incredibly high.ÿ It doesn't mean we have to have government policies to deal with the fear of zombies."

    Fear of quantum computers breaking encryption may be high, but it's not something we should actually be worrying about.
    No. But Quantum computing plus rogue super-AI plus a moronic and crooked
    US president in charge might be.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Brown@3:633/10 to All on Wed Sep 16 11:16:48 2026
    On 16/09/2026 11:03, bart wrote:
    On 16/09/2026 08:24, David Brown wrote:
    On 16/09/2026 03:22, dave_thompson_2@comcast.net wrote:
    On Thu, 27 Aug 2026 13:39:24 -0000 (UTC), antispam@fricas.org (Waldek
    Hebisch) wrote:

    bart <bc@freeuk.com> wrote:
    ..., So what sorts of things need a 64-bit [int] range?
    ...
    3) Cryptography.ÿ 32-bit cryptographic keys are deemed inadequate
    for most purposes.ÿ So, minimal reasonably safe cryptography needs
    64-bits.ÿ And with spead of radio controlled devices (like garage
    doors) there is increasing need for cryptography.

    Not keys. 64-bit key was _barely_ adequate back when DES was
    standardized, and has been unacceptable since the 1990s. (32-bit was
    _never_ safe; during the 'crypto wars' period in the 1980s and 1990s,
    when US and Europe tried to prevent spread of decent crypto,
    the 'export' options in e.g. SSL used 40-bit _because_ "we can break
    that".) Since 2010 at latest 128-bit is minimum,and now that people
    are worried that quantum breaking will become practical, 256-bit is
    more and more required.


    There is a vast amount of stuff related to cryptography or security
    for which 32-bit is entirely fine.ÿ There are other things for which
    8096- bit is a better choice.ÿ It all depends on what you are trying
    to protect, how attacks can work, and how much real entropy there is
    in the key (rather than the key length).

    Remember, access to your bank account is secured by a number that is
    not even 14 bits - it's a 4-digit PIN.ÿ And that is secure for its
    purpose.


    But crypto does NOT operate on the whole key as a unit. Most
    algorithms operate on either 32-bit or 64-bit chunks of data and the
    same or sometimes less of the key.

    A lot of popular cryptographic algorithms are optimised to work with
    64- bit chunks, so they are convenient for efficient implementation.
    But the algorithms can work happily (albeit slowly) on 8-bit computers.


    People may be worried about quantum computers breaking current
    encryption systems, but they should not be - there is no realistic
    pathway towards quantum computers being physically or economically
    viable for the task.

    As the great philosopher Dara ? Briain said, "Zombies are at an all-
    time low level, but the fear of zombies could be incredibly high.ÿ It
    doesn't mean we have to have government policies to deal with the fear
    of zombies."

    Fear of quantum computers breaking encryption may be high, but it's
    not something we should actually be worrying about.
    No. But Quantum computing plus rogue super-AI plus a moronic and crooked
    US president in charge might be.

    Skip the "quantum computing" part, and I agree.

    The only thing quantum computers will ever be practical for is
    simulating certain quantum effects. (That is, of course, interesting
    for scientific research and I'm a big fan of scientific research.)
    Remember, using quantum computers to break RSA and other cryptographic algorithms relies on things like Shor's algorithm for integer
    factorisation, and the current record is factorising 15. (That's the
    number 15, not a 15-bit number.) They had to make a custom design specifically for that number, and even then the "computer" wasn't sure
    of the answer. Attempts to factorise 21 and 35 have failed so far.




    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Wed Sep 16 13:52:26 2026
    On 9/16/2026 12:24 AM, David Brown wrote:
    On 16/09/2026 03:22, dave_thompson_2@comcast.net wrote:
    On Thu, 27 Aug 2026 13:39:24 -0000 (UTC), antispam@fricas.org (Waldek
    Hebisch) wrote:

    bart <bc@freeuk.com> wrote:
    ..., So what sorts of things need a 64-bit [int] range?
    ...
    3) Cryptography.ÿ 32-bit cryptographic keys are deemed inadequate
    for most purposes.ÿ So, minimal reasonably safe cryptography needs
    64-bits.ÿ And with spead of radio controlled devices (like garage
    doors) there is increasing need for cryptography.

    Not keys. 64-bit key was _barely_ adequate back when DES was
    standardized, and has been unacceptable since the 1990s. (32-bit was
    _never_ safe; during the 'crypto wars' period in the 1980s and 1990s,
    when US and Europe tried to prevent spread of decent crypto,
    the 'export' options in e.g. SSL used 40-bit _because_ "we can break
    that".) Since 2010 at latest 128-bit is minimum,and now that people
    are worried that quantum breaking will become practical, 256-bit is
    more and more required.


    There is a vast amount of stuff related to cryptography or security for which 32-bit is entirely fine.ÿ There are other things for which 8096-
    bit is a better choice.ÿ It all depends on what you are trying to
    protect, how attacks can work, and how much real entropy there is in the
    key (rather than the key length).

    Remember, access to your bank account is secured by a number that is not even 14 bits - it's a 4-digit PIN.ÿ And that is secure for its purpose.


    But crypto does NOT operate on the whole key as a unit. Most
    algorithms operate on either 32-bit or 64-bit chunks of data and the
    same or sometimes less of the key.

    A lot of popular cryptographic algorithms are optimised to work with 64-
    bit chunks, so they are convenient for efficient implementation.ÿ But
    the algorithms can work happily (albeit slowly) on 8-bit computers.


    People may be worried about quantum computers breaking current
    encryption systems, but they should not be - there is no realistic
    pathway towards quantum computers being physically or economically
    viable for the task.

    As the great philosopher Dara ? Briain said, "Zombies are at an all-time
    low level, but the fear of zombies could be incredibly high.ÿ It doesn't mean we have to have government policies to deal with the fear of zombies."

    Fear of quantum computers breaking encryption may be high, but it's not something we should actually be worrying about.



    Plaintext encrypted with the default key:

    Give Q# a go... ;^)

    Link to my page that decrypts the ciphertext payload:

    https://fractallife247.com/test/hmac_cipher/drmoron/?ct_hmac_cipher=dfba227617d7b480291f5d9ab8932eb92e916d22d45d328f2e4d87828ac9165a1987b7289994d26603f28e3358f4172c78b4d8cfdc23949ae436968599e436ed0a6cf3e3ace24e91eafe72e07f7ae047339f668992d269d6f825b031

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lawrence D?Oliveiro@3:633/10 to All on Sat Sep 19 05:39:24 2026
    Subject: Re: Quantum Computing Snake-Oil (was Re: Initialization Of Static Pointer Variables)

    On Wed, 16 Sep 2026 10:03:28 +0100, bart wrote:

    On 16/09/2026 08:24, David Brown wrote:

    Fear of quantum computers breaking encryption may be high, but it's
    not something we should actually be worrying about.
    .
    No. But Quantum computing plus rogue super-AI plus a moronic and
    crooked US president in charge might be.

    Quantum digital computing, as in performing basic number-theoretic
    operations, let alone implementing Shor?s algorithm, remains just as
    far beyond reach as it was 30 years ago.

    Rogue super-AIs plus moronic and crooked political leaders of all
    stripes cannot, between them, rewrite the laws of mathematics. If
    there are weaknesses in our encryption mechanisms, they will probably
    not lie in the encryption algorithms (which have undergone rigorous
    review), but in other areas like elementary mistakes in
    implementation. Or in weak sources of random numbers. In other words,
    in places where we already know they are likely to be.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)