code refactory (cache.c) & better handling f security issues

Feature requests not specific to either the Mac OS X or GTK+ versions of Transmission
Post Reply
Astara
Posts: 50
Joined: Sun Apr 18, 2010 8:36 pm

code refactory (cache.c) & better handling f security issues

Post by Astara »

Small code improvement in cache.c:

~line 264 I see:

Code: Select all

static int cache_block_compare(const void *va, const void *vb) {
	const struct cache_block *a = va;
	const struct cache_block *b = vb;

	/* primary key: torrent id */
	if (a->tor->uniqueId != b->tor->uniqueId)
		return a->tor->uniqueId < b->tor->uniqueId ? -1 : 1;

	/* secondary key: block # */
	if (a->block != b->block)
		return a->block < b->block ? -1 : 1;

	/* they're equal */
	return 0;
}

I was thinking this would be a bit more type-safe (avoids the void*)
and is only 1 statement in the compare routine:

Code: Select all

#define negative (unsigned)2<<((unsigned)8*sizeof(int)-1)
typedef const struct cache_block * Cache_Block;

static int cache_block_compare(Cache_Block a, Cache_Block b) {
  int diffID, diffblk;

  return (diffID = a->tor->uniqueId - b->tor->uniqueId) ? 
            diffID & negative ? -1 : 1                  :   // '=' case:
            (diffblk = a->block-b->block)               ?
              diffblk & negative ? -1 : 1               : 0;
}
I was curious why you never changed the rpc parser into using
a jump table.

Have you ever considered moving toward using C++ (I can't say for sure,
but it might compile w/few or no changes under C++...)? You could
move toward a more object oriented design as new features are
implemented or as old code is retired -- i.e. not needing to change
anything, currently, but allowing for future objectification...


BTW, is the bug tracker ever going to be fixed to allow bug postings with registration? It makes sense to require registration **OR** moderation, but I know of no project (not one) that requires moderation in order to submit a bug (registration, yes, but moderation?... That sticks out like a sore thumb -- like you are trying to hide or pre-censor bugs in order to hide something, but if you want to disable public browsing on some bugs, wouldn't it be possible to be able to mark some bugs as "security sensitive", so they'd only be viewable by the submitter and project members? I.e. -- I think that's a more standard way to handle sensitive or security relevant bug submissions... Is that possible?

Tnx,
Post Reply