Brian,
IMHO, there is no memory leak - the file name is kept in a static,
and the unlock() function uses that to remove the file, after which
the memory is released. If you free and zap the string after you've
obtained the lock, there's no way to get rid of the lock file.
Additionally, you might get a core dump when unlock() tries to
free a NULL pointer (depending on the libc you're running).
You could 'improve' the function by checking lock_file before
allocting a string to it:
int lock(char *dev)
{
char hdb_lock_buffer[12];
int fd, pid, n;
char *p;
if (lock_file) {
syslog(LOG_ERR, "Already locked: lock file %s", lock_file);
return -2; /* We might want to know this happened */
}
if ((p = strrchr(dev, '/')) != NULL)
dev = p + 1;
lock_file = malloc(strlen(lock_prefix) + strlen(dev) + 1);
if (lock_file == NULL)
return -1;
strcat(strcpy(lock_file, lock_prefix), dev);
....
but that seems to be a bit of an overkill.
Take care,
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
