Decide between size_t and long

[hausdorf]

We need to know whether to use size_t and, say, int and long. libgit2 uses size_t all over the place, so the question is likely really a question about when to use it.

NOTES:

• We will need to pay special attention to converting the stuff in all structs when doing this.

[trane]

http://kerneltrap.org/mailarchive/git/2007/10/3/328772 Looks like size_t in linux is the same as an ulong, but ulong in Windows is only 32 bit, while size_t scales to 64 bit.

[hausdorf]

Good to know. Incidentally, this may make libgit run slightly slower on 32-bit machines.

[basepi]

http://en.wikipedia.org/wiki/Size_t

Adding to @trane's comment, seems that size_t has specific times that it's meant to be used, specifically when storing the size of an object. It's actual underlying size is different based on the architecture on which the program is compiled, so it seems like it might be more flexible (though less consistent) as a result.

Library functions that take or return sizes expect them to be of type or have the return type of size_t. Further, the most frequently used compiler-based operator sizeof should evaluate to a value that is compatible with size_t.

Seems like, especially since we're working on a library, anything related to size should be in size_t, and otherwise we can use longs where needed.

[hausdorf]

Apparently (so says @trane) libgit uses size_t all over the place, though. If true, it's something to consider. If not, eh, longs it is.

[basepi]

My bet is that people get in the habit of using it, and end up using it where it's not necessarily "meant" to be used. Your guess is as good as mine.

[trane]

I'm of the opinion, now, that we should use size_t when referring to size and unsigned long or long when using those types to represent data. Thoughts?

[basepi]

Sounds like a solid idea to me.

[trane]

I think we are pretty much in agreement here. I'll close this issue.

[hausdorf]

Turns out that size_t is a typedef of some unsigned integral type (e.g., int or long) whose range is guaranteed to be able to hold the size in bytes of the biggest object your machine can possibly hold. Thus size_t, in case you're wondering, should be used any time you want to describe something of arbitrary size. So, for example, an index in a for loop.

There's a bit about it here.

[basepi]

Woot, another misuse of the classic size_t. Oh well.

Then again, it might not be a misuse, I just may have the wrong idea about size_t -- plus, wikipedia is not infallible. By any stretch.

[hausdorf]

What misuse, now?

[basepi]

Eh, just seems like that doesn't fit in with the use of size_t in the wikipedia article I referenced previously.

https://github.com/crakdmirror/libgit2/issues/16#issuecomment-1042583

[hausdorf]

So, specifically, on the second page of the link above, just before the section titled "Using size_t", it says:

Type size_t is a stypedef that's an alias for some unsigned integer type, typically unsigned int or unsigned long, but possibly even unsigned long long. Each Standard C implementation is supposed to choose the unsigned integer that's big enough--but no bigger than needed--to represent the size of the largest possible object on the target platform.

[basepi]

Second page? It's a wikipedia article, it's not paged....

[basepi]

But I'm not arguing the standards of how big size_t needs to be -- it's defined to be used for any variable required to hold a size. That way, it can hold the maximum integer value on both a 32-bit and a 64-bit platform, or whatever. So you don't use it anywhere you need an arbitrarily large container -- rather, you use it anywhere a size is returned or referenced.

That's my impression, anyway.

[hausdorf]

This link that I mentioned here.

[basepi]

LOL, thought you were referencing my link above. So confused.

See my comment.

[basepi]

And again, I don't know that I'm correct, it's just how I understood it.

[hausdorf]

What you are responding to is not what I'm talking about. The only take-away point here is that the size_t is guaranteed to be able to address any byte in memory, and it is guaranteed to not be bigger than it needs to be.

[basepi]

I agree on that point.

I was referencing your statement as to how size_t should be used in this comment. Technically (as far as I can tell), it shouldn't just be arbitrarily used anywhere you need a counter -- rather, in instances regarding the size of an object, or an address in memory or something like that.

[hausdorf]

I didn't say that you should use it anywhere you need a counter. If you're counting to 4, you should use any integral type smaller than or equal to word size, since mov is equivalent for, say, int and char (usually). What I'm saying is, when you're describing something of arbitrary size, e.g., bytes in a file, it should definitely be in size_t.

Specifically what I was talking about is that the general case of a for loop is dependent on something that is arbitrarily-sized: I will write probably a hundred for loops that stop at some $SIZE variable for every one that I will write that counts to a magic number.

[basepi]

Gotcha. Man alive, we're bad at this whole communication thing -- we've been arguing the same point for the last 10 comments, methinks. We do that a lot. =P

[hausdorf]

Indeed.