[question] What does `big` mean in bitflags

[ItsDrike]

Hey, I’ve been going over the various types in protocol.json, and I noticed that the bitflags type sometimes includes a boolean field named big.

I’m trying to understand what this field actually means. My assumption is that it’s related to endianness, but how should that be interpreted here exactly?

For example, in Bedrock 1.21.100, the type protocol/types/InputFlag looks like this:

[
  "bitflags",
  {
    "type": "varint128",
    "big": true,
    "flags": [
      "ascend",
      "descend",
      "north_jump",
      "jump_down",
      "sprint_down",
      "change_height",
      "jumping",
      "auto_jumping_in_water",
      "sneaking",
      "sneak_down",
      "up",
      "down",
      "left",
      "right",
      "up_left",
      "up_right",
      "want_up",
      "want_down",
      "want_down_slow",
      "want_up_slow",
      "sprinting",
      "ascend_block",
      "descend_block",
      "sneak_toggle_down",
      "persist_sneak",
      "start_sprinting",
      "stop_sprinting",
      "start_sneaking",
      "stop_sneaking",
      "start_swimming",
      "stop_swimming",
      "start_jumping",
      "start_gliding",
      "stop_gliding",
      "item_interact",
      "block_action",
      "item_stack_request",
      "handled_teleport",
      "emoting",
      "missed_swing",
      "start_crawling",
      "stop_crawling",
      "start_flying",
      "stop_flying",
      "received_server_data",
      "client_predicted_vehicle",
      "paddling_left",
      "paddling_right",
      "block_breaking_delay_enabled",
      "horizontal_collision",
      "vertical_collision",
      "down_left",
      "down_right",
      "start_using_item",
      "camera_relative_movement_enabled",
      "rot_controlled_by_move_direction",
      "start_spin_attack",
      "stop_spin_attack",
      "hotbar_only_touch",
      "jump_released_raw",
      "jump_pressed_raw",
      "jump_current_raw",
      "sneak_released_raw",
      "sneak_pressed_raw",
      "sneak_current_raw"
    ]
  }
]

There are 65 flags here for a varint128 with "big": true. How should I interpret this?

I understand that Minecraft varints themselves are always little-endian, so I don’t suppose this flag refers to byte order. My current theory is that it's about the bit order - that is, whether flag 0 corresponds to the most significant bit or the least significant bit.

Is that correct? Or does "big" mean something else in this context?

[extremeheat]

The big is simply a flag for bigint in js. Endianness is encoded per type

[extremeheat]

All varints are little endian. Because high bit is used for multibyte integers like utf8

[ItsDrike]

Oh, I see, thanks for clarifying.

That said, this seems like a pretty odd design choice, given that minecraft-data is meant to be language-agnostic. If "big" is only meant to signal that JS needs a BigInt, that feels like something the consuming library could infer directly from the underlying type (it seems fairly obvious that a varint128 implies a potentially large value that might not fit into a regular integer type in some languages, having an attribute for it just seem redundant).

Or is there’s some specific case where "big" actually conveys extra meaning beyond that? The only thing that comes to mind there would be if the types without "big": true represent types where the max value ranges never reach bigger values, even if the underlying type technically can?

If that’s not the case, and this really is just a JS-specific hint, it might make sense to drop it from the data entirely, since it could end up introducing more confusion than it solves (for example, if big isn't specified somewhere, but the type can still reach large values, implementations might choose the wrong data type). The name "big" also makes it easy to mistake for something it's not, especially without any schemas or docs to explain it.

If it does need to stay, perhaps renaming it to something like jsBigInt could help clarify its purpose. Of course, both renaming or removing it would be breaking changes here, so I'm not sure if doing that is acceptable.

[extremeheat]

It has nothing to do with JS. It's information for code to not have a hard coded map on what kind of integer it's working with.

I agree the name is bit confusing with endianness and maybe better name is bigint. But since endianness is encoded in the type it's not an issue. It's for outside code to process after (or prepare before) the decode. In some cases you can ignore it if the language already provides arbitrary sized integers. But for everything else (Java, JavaScript, c++, etc) they all need to use special data structures and therefore simply get that extra hint.

[ItsDrike]

Okay, but even if this isn't JS specific, I still feel like the structure used for the keys of a mapping storing this for this data-type should always be inferrable from the type.

E.g.: If there's a bitflags object with "type": "varint128" the implementations should already be able to see that to construct the mapping, they'll need to declare it with keys of a numeric type that can hold these large numbers. On the other hand, if it had "type": "u8", the implementation can do optimizations to maybe have the mapping hold a char type or whatever type that represents such numbers to save space.

Point here being that the number type used should depend on the actual underlying type used in the structure, it shouldn't just be some default number type or a big number type if big is set. And even if that was how implementations wanted to do this, not caring about the memory, it's still inferrable by maintaining a list of big native types (since AFAIK the type here can only ever point to one of the native numeric types), so why even encode this information into minecraft-data when it's entirely redundant and inferrable?

Just to be clear, I’m not saying it must be removed, even if it's redundant, it can simplify the check for implementations a bit, just trying to understand whether there are any cases where "big": true actually provides information that can’t be inferred from the "type" and if not, whether it really is worth keeping it around, when a more dynamic logic based on the type would likely make more sense for implementations anyways.

[DereC4]

bigendian

comparch flashbacks