Why is `size` defined as an int64 for OCI content descriptor?

[asridharan]

I would think size should be described as uint64 ?

[wking]

On Thu, Sep 29, 2016 at 09:06:11AM -0700, asridharan wrote:

I would think size should be described as uint64 ?

More discussion on this in #153.

[asridharan]

I still don't understand the reasoning behind this decision. The only thing I see from the conversation seems to be its okay to use int64 since we "don't" allow negative values, and somehow the motivation seems to be that "go" has done it this way. A spec should not be language specific, so seems very arbitrary at this point.

Also, the fact that size is expected to be positive and validation needs to be performed has not been stated in the spec. Just being "picky" here since this is the spec and should be treated as a gold standard. The reasoning has to be beyond question.

[wking]

On Thu, Sep 29, 2016 at 12:04:34PM -0700, asridharan wrote:

I still don't understand the reasoning behind this decision.

I would also prefer to see an unsigned integer, but was unable to make
a convincing-enough case for it.

… and somehow the motivation seems to be that "go" has done it this
way.

The compat argument wasn't about Go, it was that docker/distribution
uses int64 1. But docker/distribution uses different media types,
and all reasonable size values will fit into both an int64 and a
uint64, so I don't see a problem with switching the OCI type to use
uints that carry at least 64 bits (more discussion in #153 where I
argue for following C and JSON in not capping the maximum size).

Also, the fact that size is expected to be positive and validation
needs to be performed has not been stated in the spec.

The non-negative-ness is covered by the existing 2:

This REQUIRED property specifies the size, in bytes, of the raw
content.

because you can't have negatively-sized content.

Validation is covered by the existing 3:

If the length of the retrieved content does not match the specified
length, the content SHOULD NOT be trusted.

The only thing wrong about using a signed integer to store that
information is that you're wasting a bit and inviting this “why is
this signed?” confusion ;).

[asridharan]

thanks @wking . Missed the argument of docker using int64. Yeah I agree using int64 rather than uint64 seems like an unecessary confusion to percolate into the spec.

I wasn't aware the spec "needed" to be compatible with docker specification. I thought the idea was to move forward and look for something that is not tied to current specs? If anything I would imagine docker should chaging its spec to come closer to what OCI decides rather than the other way round.

[jonboulle]

For most of the reasons already discussed I'd prefer uint64, and I'm not convinced by the reasoning for staying with int64 - so, you would have my +1, but I am not going to drive this.

[stevvooe]

We've already discussed this in detail and made a decision. Let's not reopen this discussion.