asciilifeform: mircea_popescu: 'carry' on most chips refers to a physically separate 1bit register. but sure

asciilifeform: the top of the result, rather. but yes. on x64 you could!!! have the Right Thing bignumtron.

asciilifeform: nope. x86 (and correspondingly x64) mul gives you ~two~ buswidth-sized results, the bottom and top half of the result.

asciilifeform: that doesn't set the carry on x86...

asciilifeform: now take mul .

asciilifeform: aha, for add / sub it is trivial

asciilifeform: problem comes with multiplication

asciilifeform: for addition, this is actually simple on most chips, there is a 'carry' flag

asciilifeform: to make bounds checking happen, on whatever particular cpu, gotta emit not only the add instruction but a few others also

asciilifeform: is not how 'add' instruction works.

asciilifeform: the cpu NEVER DOES THIS omfg

asciilifeform: in this case aha.

asciilifeform: in this example. and it gotta signal the overflow.

asciilifeform: y is of the constrained type contemplated.

asciilifeform: let x == 0xfffffffffffffff . y = x + 1. is y in range ?

asciilifeform: right! but in order for the machine to KNOW that it cannot, the ranges have to be representable.

asciilifeform: the thing will not, like idiot cpp does, emit some 'but he REALLY WANTED THIS...'

asciilifeform: mircea_popescu: if you write down a statement that is logically impossible to transform into compiled code, per the ground rules, it is a compiletime eggog.

asciilifeform: 'you asked me to make 2 equal 4, go fuck yerself'

asciilifeform: instead it barfs.

asciilifeform: comparing to 0xffffffffffffffff is not what the program stated, in the example. and since the compiler is sane, it does not substitute a semantically variant statement to what programmer wrote, under any circumstances.

asciilifeform: guaranteed. try it yourself.

asciilifeform: mircea_popescu: it makes no difference !

asciilifeform: if you want sane runtime safety.

asciilifeform: you're stuck with 1 bit smaller quantities than the full bus width.

asciilifeform: that you can't do this for full machine-width integer. for fundamental reason, turns out.

asciilifeform: it isn't a compile-time static thing

asciilifeform: in same language, program throws ~runtime~ exception if you EVER try to assign the 11, no matter how it was arrived at

asciilifeform: mircea_popescu: 'programmer said 11 -- we beat him with a stick' is trivial. of concern is arithmetic overflow/underflow.

asciilifeform: let's revisit the particular of how you can even end up with an X that no longer sits down in 64 bits, using an op on an A and a B which ~do~

asciilifeform: how do you compare to a bound that needs moar bits to represent than the number you are comparing ?

asciilifeform: pick a cpu, any cpu, let's work example ?

asciilifeform: the fact won't go away if you put head in sand.

asciilifeform: think for a minute.

asciilifeform: srsly

asciilifeform: maxint+1 DOESN'T SIT DOWN IN YOUR REGISTER

asciilifeform: on any box!

asciilifeform: problem is that you cannot represent MAXINT+1 as a constant !!

asciilifeform: by comparison to a constant.

asciilifeform: it implements it in the only way that is guaranteed to be invariant, and run in constant spacetime, on all iron.

asciilifeform: and other beautiful things.

asciilifeform: y'know, the one where the boeing 787 engine melted.

asciilifeform: it is NOT the same as 'modular arithmetic', modular arithmetic is the behaviour of the native iron that we are going AWAY from here.

asciilifeform: same as if you try to add 1 to a foo where type Foo is range 0 .. 10; and Q: Foo; and Q was already 10.

asciilifeform: we gotta ring red alarm , reactor is melting, if an arithmetic op results in exceeding range.

asciilifeform: to cut it.

asciilifeform: BUT WE DO NOT WANT

asciilifeform: mircea_popescu: what the fuck will a mod do ??

asciilifeform: mircea_popescu: in all fairness this was only a surprise to asciilifeform because he is a n00b; the b00k warns explicitly, in black on white letters.

asciilifeform: (a set of comparisons gets inserted by compiler on any operation that could result in walking out of the bounds)

asciilifeform: they are necessarily implemented on top of machine fixints.

asciilifeform: but ada also introduces notion of sane (non-underflowing and non-overflowing, and in fact arbitrarily constrained) types.

asciilifeform: this comes with the territory of 'naked' register. in ada you have to explicitly ask for this horror, it is called 'modular type'. all c types are it.

asciilifeform: fixnum is the term of art for the mathematical object that you end up with when you arithmetize on registers of particular physical size.

asciilifeform: it has finite bitness.

asciilifeform: whole notion of a fixnum, is this.

asciilifeform: think: you can cmp rax, 0xffffffffffffffff . but you cannot cmp rax, 0x10000000000000000 , it dun matter how much you want to.

asciilifeform: mircea_popescu: on no extant cpu can you apply range constraint predicate to a bus-wide fixnum. think about it.

asciilifeform idly wonders if ye olde https://www.engadget.com/2015/05/01/boeing-787-dreamliner-software-bug/ was an instance of 'can't do 64bit unsigned int as constrained range type on any extant iron'

asciilifeform: we are looking at a real engineering constraint, flowing from the broken way in which c-machine implements the ring of integers.

asciilifeform: http://btcbase.org/log/2016-10-03#1551706 <<< directly related old thread. ☝︎

asciilifeform: some idiot ~could~ enable receipt of 4GB messages. but exabyte ??

asciilifeform: inline unsigned int SendBufferSize() { return 1000*GetArg("-maxsendbuffer", 10*1000); }

asciilifeform: inline unsigned int ReceiveBufferSize() { return 1000*GetArg("-maxreceivebuffer", 10*1000); }

asciilifeform: as for mempool messages, we have , in current trb :

asciilifeform: (a 1MB block cannot, no matter how much you might want, ever hold > 1048576 of ANYTHING!)

asciilifeform: varint-wise.

asciilifeform: pretty sure that nothing ever hits even 2**32-1.

asciilifeform: or not.

asciilifeform: proposition: 'no valid bitcoingram contains a varint greater than 2**63 -1 ', let's say. tru?

asciilifeform: 2**64 is a 65-bit number.

asciilifeform: (2**64 -1 rather !!!!)

asciilifeform: ben_vulpes ? et al

asciilifeform: mircea_popescu ^ does this match your calculation ?

asciilifeform: that being said, my current understanding is that no bitcoin message containing a varint equalling 2**64 is ever possibly valid.

asciilifeform: this, i suppose, is not a mega-discovery, it is just trivial fact that you cannot 100% match the semantics of a broken system without being broken in all of the exactly same ways (in this case, over/under-flowable arithmetic)

asciilifeform: (by injecting a 2**64 varint in some message.)

asciilifeform: BUT! now an enemy can distinguish your node from satoshi node, by when the connection barfs. potentially.

asciilifeform: this will never result in a block verification eggog (varints are used ONLY for counts of entitites, and no bitcointronic subentity contains 2**64 of anything, or could, by the classical rules)

asciilifeform: (and then define the correct reader, writer, for streams, i am omitting these here for clarity)

asciilifeform: let's say we go type Btc_Varint is range 0 .. (2**63)-1;

asciilifeform: i will explain why:

asciilifeform: but this is small comfort

asciilifeform: now! IN PRACTICE! any bitcoin message with a 0xFFFFFFFFFFFFFFFF varint in it, is an eggog, because max message length is smaller than this.

asciilifeform: and the 'doctor, it hurts when i do that! --- so stop doing that!' option is NOT available, as bitcoin's protocol mandates a 'compactsize' variable-bitness integer idiocy that maxes out at unsigned 64bit. ( see http://btc.yt/lxr/satoshi/source/src/serialize.h?v=asciilifeform_add_verifyall_option#0192 ) .

asciilifeform: this is not as simple as 'gcc suxxxxx, let's fix gcc'. because i have nfi what The Right Thing looks like here.

asciilifeform: this is, as i see it, a philosophical problem, and i post it here for that reason.

asciilifeform: so you ~must~ have fixnum arithmetic.

asciilifeform: likewise default assumption in ada world is that there is not necessarily a heap. (safety-critical proggies typically use NO HEAP EVER)

asciilifeform: and no, you can't gabriel_laddel over this boojum, and 'work around in software automagically', result will be a massive time AND space penalty at a seemingly arbitrary boundary (i.e. if you had bignumatron kick in above the can't-fixnum-no-moar threshhold)

asciilifeform: seeeee this is what i mean when i say 'hardware is catastrophically retarded'

asciilifeform: but if there is no fixint superset, there cannot, apparently, exist the constrained type.

asciilifeform: even type Foo is range 0 .. (2**63)-1; worx on x64, because there is a superset, i.e. range 0 .. 2**64 .

asciilifeform: so it'll turn type Foo is range 0 .. 10; into type Foo is Integer range 0 .. 10 ;

asciilifeform: as per ada standard, in order to have a constrained type (e.g., type foo is range 0 .. 10; ) the compiler must find a X such that X is representable on the machine as a fixint, and range of X is larger than asked-for range

asciilifeform: it's an abstraction leak that is not trivially pluggable.

asciilifeform: i've been pondering subj for ~hour nao; it is not entirely clear that '100% machinewordsize-independent arithmetic' is compatible with 'zero-surprise compilation on all machines'

asciilifeform: mircea_popescu: even this, is debatable

asciilifeform guesses that they belong to luser boxes, i.e. konsoomer routers, no ssh

asciilifeform: 30s