[Oberon] Negative integer literals in Oberon

[Jörg]

Yes, one might see cryptographic as one case, where hex and calculation might fit.

The first sentence in RFC1321 MD5 hash states:
   This document describes the MD5 message-digest algorithm. The
   algorithm takes as input a message of arbitrary length and produces
   as output a 128-bit "fingerprint" or "message digest" of the input.

128 bit output is very concrete presentation layer, and when mapping that to a program, most algorithms use deep implementation knowhow to optimally organize these bits in memory. What the algorithms are basically doing, they simulate calculations on a 128 bit bitfield, knowing that the useful entity they can work with on their machine is a 32 bitfield.

So, principally they define BIT128 and they write a MODULE to make some fancy stuff on this type.
With the help of the compiler SYSTEM.SIZE(INTEGER) you know the nbr of bytes, but you can only guess that the MSB is the sign. It's up to the compiler and the CPU to decide.

If you look at the reference implementation in C you find
   context->state[0] = 0x67452301;
   context->state[1] = 0xefcdab89;

The 0xefcdab89 has for sure nothing to do with an INTEGER. Even if you know that the compiler fits the sign bit into the MSB, the MSB of the expression 0xefcdab89 is not a sign.

br
Jörg

Am 28.04.20, 14:51 schrieb "Oberon im Auftrag von Michael Schierl" <oberon-bounces at lists.inf.ethz.ch im Auftrag von schierlm at gmx.de>:

    Am 27.04.2020 um 22:10 schrieb Jörg:
    >
    >>    ASSERT(0FFFFFFFFH = -1) (*require two's complement *)
    >
    > On strict compilers this statement does not even compile as 0FFFFFFFFH is not a valid INTEGER.
    >
    > Could somebody give me a good example, where INTEGERs need a hex notation?
    
    Depends how exactly you define "INTEGERs" for. If I understand you
    correctly, in your opinion INTEGERs are the data type that is used for
    arithmetic operations without caring of the memory layout.
    
    In that case, it is quite common to give cryptographic parameters (e.g.
    RSA modulus or ECC curve parameters) in hexadecimal. Most of them
    (except the infamous 0x010001) will not fit into a 32-bit INTEGER, but
    still they are defined in Hex and you do arithmetic (multiplication,
    addition, exponentiation, modulus, modInverse) with them and hope that
    no overflow happens.
    
    AES keys or checksums are also often given in hex, but in this case the
    size and representation of the values is also fixed, so probably a
    purist would use a different data type than (BIG)INTEGER for it.
    
    
    Regards,
    
    
    Michael
    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon