Store startOffset + length instead of startOffset + endOffset

[eregon]

From #741 (comment)

Doing so is simply better for the serialized size, because length is always <= endOffset, and often much smaller.

I think it might make sense to change it everywhere, but we could also just change it for serialization.
@jemmaissroff WDYT?

[eregon]

Actually it seems much easier to only change it for serialization for now, as that has much less potential for conflicts, etc.
And performance-wise it's likely no big deal either way.

So it's more about consistency and what's more useful to track inside C structs.

[eregon]

Now that #873 is merged, I think we should change it for Java Nodes and Ruby Locations, because that avoids extra work like #873 (comment) and also some places need to recompute the length from end_offset - start_offset which feels inefficient.

I'm not sure about C nodes structs though, WDYT @jemmaissroff ?
That's probably a lot more involved to change, so if we do that, I think best to do it separately.

[jemmaissroff]

I think we should prioritize keeping it consistent. I'm worried we'll make the changes for Java Nodes and Ruby Locations, and then add the C Nodes to the backlog without committing to doing it.

[eregon]

Actually there is an advantage to store it as (start, length) for C structs too because sizeof(char* end) = 8 but sizeof(uint32_t length) = 4.
Potentially we could also store the start as a uint32_t offset from parser->start instead of char* and that would again save 4 bytes.
Currently:

typedef struct {
  const char *start;
  const char *end;
} yp_location_t;

[eregon]

@jemmaissroff Should we change it for C structs too? How do we do that without having huge conflicts?

[eregon]

I gave it a shot at main...eregon:yarp:c-struct-length, that compiles but many offsets are wrong, there must be some mistranslation.
Given the frequent usage of end while computing locations in yarp.c, I think it might be best to just keep it as-is, it's far more convenient.

[kddnewton]

This works in the serialization, but I think it would not be worth it in the actual library. I'm going to close this now that we have it in the serialization.