Is it possible to calculate the plaintext length of an RC5-32 encrypted ciphertext?

Calculating the RC5 encrypted size of any data is as simple as rounding up the plaintext length to the nearest multiple of 8. What I'm wondering is whether this can be done in the other direction, to get the length of the original plaintext data given the ciphertext. Obviously this information isn't revealed until the decryption actually happens, but can it be tracked/calculated during the decryption process?

I'm working with this implementation of RC-5 decryption (decompiled C++ binary, re-implemented in C#), which decrypts the data in groups of 4 bytes, and copies the result into the output buffer. The problem is, there's a lot of garbage in the output buffer after the end of the decrypted data, so it's hard to determine where the data actually ends. It's easy if the plaintext is a null-terminated string, but I'm looking for a more generic solution that can work on arbitrary binary data.

What I'm wondering is whether this can be done in the other direction, to get the length of the original plaintext data given the ciphertext.

RC5 is a block cipher; what you're asking about is about the block cipher mode (and what padding that implementation uses); there isn't enough information to answer your specific question; however I do have a guess.

A "block cipher" is an invertible transform from an n-bit bitstring (in this case, $n=64$) to an n-bit bitstring. What a "block cipher mode" does is that the "block cipher" and uses it in a way to make a more generally useful operation, for example, encrypting an arbitrary length plaintext.

Now, glancing at the code, it would appear that the code uses "ECB mode" to encrypt the string (which is generally a bad choice - of course, that's not your problem). With "ECB mode", the mode itself can only handle plaintexts that are a multiple of the block length (in this case, 16 bytes) in length. Because we generally want to handle arbitrary length plaintexts, what we do is add "padding", that is, some extra stuff at the end to make the length a multiple of 16 bytes in length (which the mode can then handle).

This padding is designed in a way to make removing the padding at decryption time easy - however there are several possibilities and the decrypt code you gave doesn't tell us which one is being used. In the most common mode, the very last byte is used to signify the number of padding bytes that were added - you might want to see if that's the case in your examples.