Skip to content

Commit dc53d88

Browse files
committed
Add a code comment
1 parent 90212a2 commit dc53d88

2 files changed

Lines changed: 8 additions & 5 deletions

File tree

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -144,7 +144,7 @@ Example: scan `3fff:1234:1234:44xx::` -> response from `3fff:1234:1234:44a3:e2a:
144144
### Target randomization
145145

146146
The way fi6s randomizes the scanned IPs (`--randomize-hosts 1`, which is the default)
147-
is not perfect.
147+
is far from perfect.
148148

149149
It will:
150150
* shuffle IPs in batches of 8192

src/target-gen.c

Lines changed: 7 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -459,10 +459,13 @@ static void next_addr(struct targetstate *t, uint8_t *dst)
459459
// above remains correct.
460460

461461
// Note: I tested __uint128_t for this too. GCCs code is extremely slow;
462-
// clang is fine, but it's still slower than this 64-bit implementation.
463-
// Note 2: reading the bytes as LE - or in any other order - would not
464-
// make the results incorrect, just "randomize" them a little.
465-
// However we want to keep the natural order.
462+
// clang is fine, but it's still slower than this 64-bit implementation.
463+
// Note 2: Using __builtin_addcll this could be rewritten in a nice, entirely
464+
// branchless manner (just 24 x86-64 instructions). That however turns out
465+
// to be slower than the current branchy code. wat.
466+
// Note 3: reading the bytes as LE - or in any other order - would not
467+
// make the results incorrect, just "randomize" them a little.
468+
// However we want to keep the natural order.
466469

467470
uint64_t m0 = read_be64(t->spec.mask), m1 = read_be64(t->spec.mask + 8);
468471
uint64_t c0 = read_be64(t->cur), c1 = read_be64(t->cur + 8);

0 commit comments

Comments
 (0)