3 ms·

I'm not sure I get you - "not 0" is a more predicable value than a certain number, isn't it?

by stefs 1y ago

kevincox 1y ago
I'm talking about output. For sure, if I am reading this bool from FFI I want to have "not 0" be truthy. However if I am writing a bool to a FFI interface I want the value to be predictable (for example 1) rather than "some non-zero value". Although this does open interesting cases where if you read a bool from one FFI interface and write to another it may have an unexpected value (ex 2). But I still think it is useful for the in-language conversions for example Boolean to LongBool and the True constant to have predictable values.
saurik 1y ago
I presume this FFI goes in both directions; some APIs really want the value of a boolean to be 1 while others really want it to be "all 1s"/0xfff.../-1 because, internally, someone decided to do something silly and compare == or switch on TRUE.
- masfuerte 1y ago
  The .Net runtime generates code that relies on bools being either 0 or 1. It's quite easy using interop to inadvertently set a bool to something else and this leads to very odd bugs where simple boolean expressions appear to be giving the wrong result. (Tangentially, VB traditionally used -1 for true. VB.NET uses the same 0 or 1 internal representation for a bool as C# but if you convert a bool to a number in VB.NET it comes out as -1.)
  - da_chicken 1y ago
    -1 isn't even a bad choice, since that's basically using 0xFF for true and 0x00 for false. The weirdness is the fact that you're converting a binary value to a signed integer.
    - int_19h 1y ago
      This goes all the way to early BASIC, and it's signed because the language didn't have any unsigned numbers to begin with. The main reason for this particular arrangement is that, so long as you can rely on truth being represented as -1 - i.e. all bits set - bitwise operators double as logical ones. Thus BASIC would have NOT, AND, OR, XOR, IMP, EQV all operating bitwise but mostly used for Booleans in practice (it misses short-circuiting, but languages of that era rarely defaulted to it).
      - saurik 11mo ago
        If you can rely on truth being represented as 1 (or 3, fwiw) the same bitwise operations work fine.
        int_19h 11mo ago
        NOT doesn't
    - hyghjiyhu 1y ago
      A lot of the time variables will be in registers. And registers are basically ints. That would be my guess for why many things are ints that could fit in less space.

I'm not sure I get you - "not 0" is a more predicable value than a certain number, isn't it?

by stefs 1y ago

I'm not sure I get you - "not 0" is a more predicable value than a certain number, isn't it?

I'm talking about output. For sure, if I am reading this bool from FFI I want to have "not 0" be truthy. However if I am writing a bool to a FFI interface I want the value to be predictable (for example 1) rather than "some non-zero value". Although this does open interesting cases where if you read a bool from one FFI interface and write to another it may have an unexpected value (ex 2). But I still think it is useful for the in-language conversions for example Boolean to LongBool and the True constant to have predictable values.

saurik 1y ago

I presume this FFI goes in both directions; some APIs really want the value of a boolean to be 1 while others really want it to be "all 1s"/0xfff.../-1 because, internally, someone decided to do something silly and compare == or switch on TRUE.

masfuerte 1y ago
The .Net runtime generates code that relies on bools being either 0 or 1. It's quite easy using interop to inadvertently set a bool to something else and this leads to very odd bugs where simple boolean expressions appear to be giving the wrong result. (Tangentially, VB traditionally used -1 for true. VB.NET uses the same 0 or 1 internal representation for a bool as C# but if you convert a bool to a number in VB.NET it comes out as -1.)
- da_chicken 1y ago
  -1 isn't even a bad choice, since that's basically using 0xFF for true and 0x00 for false. The weirdness is the fact that you're converting a binary value to a signed integer.
  - int_19h 1y ago
    This goes all the way to early BASIC, and it's signed because the language didn't have any unsigned numbers to begin with. The main reason for this particular arrangement is that, so long as you can rely on truth being represented as -1 - i.e. all bits set - bitwise operators double as logical ones. Thus BASIC would have NOT, AND, OR, XOR, IMP, EQV all operating bitwise but mostly used for Booleans in practice (it misses short-circuiting, but languages of that era rarely defaulted to it).
    - saurik 11mo ago
      If you can rely on truth being represented as 1 (or 3, fwiw) the same bitwise operations work fine.
      - int_19h 11mo ago
        NOT doesn't
  - hyghjiyhu 1y ago
    A lot of the time variables will be in registers. And registers are basically ints. That would be my guess for why many things are ints that could fit in less space.