Hello all,

I was just wondering if anyone knew about this issue. From what I understand, crypt() uses a statically allocated buffer to store it's output when doing encryption, and returns a pointer to that buffer, much like the readdir function. Now, the issue really is just that valgrind complains when I run a full memcheck with it after my program uses crypt. However, if I try to free the memory and crypt is called a seccond time I get a much worse error, that previously unallocated memory is being written to.

This isn't really a problem as far as I can see, my program runs fine, and linux is clever enough to clean up the 65 bytes that crypt never frees, but I would like to know if I'm missing a crypt-free() routine or something, or if this is simply a bug in valgrind.

Anyone have any ideas?
Thanks,
--Xagafinelle

(P.S. I couldn't find much documentation on crypt-lib, there may be something I'm missing, although the functions work great!)

(P.P.S. I am using C++ on a linux system, and as far as I know I have the latest version of libcrypt. Yeah, you heard me, C++ Strike... )

It looks that crypt's using the same buffer for all results it returns. It doesn't look like a valgrind bug - such things just happen. I don't know nothing about crypt-free or something like thath Haven't looked into crypt sources, through.

Well, right, it maintains a single buffer, more or less, it does use a realloc on it if you call it again. But it definately is not static, is my point, and valgrind knows this.

What I was asking was that if this is really not an issue because the memory is being free'd and valgrind is checking it too early, or something of that nature, I know there were plenty of issues like that in previous versions, or if this is an issue in crypt itself, since there is no easy way for me to free this memory.

Really, I just want valgrind to return a clean report, there's a certain amount of pride there, 'sides, it looks nicer.

I checked the headers for libcrypt, and they have nothing in them but the crypt functions, and nothing else.

Anybody?
--Xagafinelle

There are a number of librarues which find it OK to have one constant memory "leak", that means some permanent data structure is allocated once at library startup and never cleaned up.[*]

Re-run the test to see whether 1000 uses of the library cause more memory to leak.
[*]Don't blame them too hard, they just want to avoid requiring the user to call some shutdown function and many people don't like to register random atexit() handlers.