Topic: TAR Archive Support (xmp-tar)

[Keltic Danor]

Hello hello,

Not usually my department but I'm exploring a bit and made a little archive plugin that adds TAR support, not sure if we have that already but if not here we go! It's mostly an experiment to see if I could figure it out and I did TAR because there is no compression involved to simplify things for me.

It supports tar.gz files too although you'll need the GZIP archive plugin as well for that. It may or may not explode with very large TAR files but I doubt that will be that big of a deal.

TAR v1.1
Source is available via the support site as well.


While it all seems to work I do have a question though that someone might be able to explain to me... I've added notes of what I *think* is happening, but I'd like anyone's 2c on it.

Code: [Select]

This is to build a file list for XMPlay

int p = 0;
-snipped loopy loop stuff-
fl=(char*)xmpfmisc->ReAlloc(fl,p+100+2);
// XMPlay allocates memory for me to use and a fancy pointer to it?

memcpy(fl+p,e.name,100);
// I copy 100 bytes to the fl memory pointer provided above, +p is an offset maybe?

fl[p+100]=0;
// I null terminate the string that was copied over

p+=strlen(fl+p)+1;
// strlen returns the length of the string that is in fl +p with p providing the offset again? + 1 for the null terminator. So "MOOSE" would be 5 + 1, so p+=6 in that case

fl[p]=0;
// I add another null termination to the string to finish it off for XMPlay, if there is another loop this is overwritten by the next e.name?
-snipped loopy loop stuff-

That's what I think it does, but what does it actually do? 

[Ian @ un4seen]

Yep, those comments look correct. "p" is the current length of the file list. The file list is terminated with a double-null, so that's the reason for the "+2" in the ReAlloc call and the "fl[p]=0" line. You could change "I null terminate the string that was copied over" to "I null terminate the string that was copied over just in case it isn't already". For clarity, you could also change the instances of "100" to "sizeof(e.name)", as that'll be what it's based on.

[Keltic Danor]

...you could also change the instances of "100" to "sizeof(e.name)", as that'll be what it's based on.

Ah I think that is actually where I was getting stuck.

I just assumed if I was allocating 102 for example then when I add the next file in the list the new position would always be 100 more because that's how up to how many bytes the names were.

Makes sense why XMPlay was saying no to that.