The hash_table shared-library implementation returns -1 from ConflictSet::getBytes() and ConflictSet_getBytes(), which contradicts the API contract documented in include/ConflictSet.h that the function "Returns the total bytes in use by this ConflictSet".
getBytes() should return a non-negative value representing the memory in use by the hash table implementation, consistent with the radix tree and skip list implementations. If tracking memory is intentionally not supported, the function should at least return 0 and the exception should be documented; returning -1 is not a valid byte count and violates the documented contract.
Impact
Any user code or binding (e.g. the Python wrapper) that loads the hash_table implementation and checks cs.getBytes() > 0 will incorrectly conclude the conflict set is empty.
The returned value is silently incompatible with the documented semantics, making the hash_table implementation non-interchangeable with the other implementations for callers that inspect memory usage.
The `hash_table` shared-library implementation returns `-1` from `ConflictSet::getBytes()` and `ConflictSet_getBytes()`, which contradicts the API contract documented in `include/ConflictSet.h` that the function "Returns the total bytes in use by this ConflictSet".
## Location
- `HashTable.cpp:99` — `int64_t ConflictSet::getBytes() const { return -1; }`
- `HashTable.cpp:163-166` — `ConflictSet_getBytes` also hard-codes `-1`.
## Reproduction
1. Build the hash_table target:
```sh
cmake --build build --target hash_table
```
2. Compile and run a small C program linked against `build/hash_table/libconflict-set.so`:
```c
#include "ConflictSet.h"
#include <stdio.h>
int main(void) {
ConflictSet *cs = ConflictSet_create(0);
ConflictSet_WriteRange w = {{(const uint8_t *)"0000", 4}, {NULL, 0}};
ConflictSet_addWrites(cs, &w, 1, 1);
int64_t bytes = ConflictSet_getBytes(cs);
printf("%ld\n", bytes);
ConflictSet_destroy(cs);
return 0;
}
```
3. Actual output:
```
-1
```
## Expected behavior
`getBytes()` should return a non-negative value representing the memory in use by the hash table implementation, consistent with the radix tree and skip list implementations. If tracking memory is intentionally not supported, the function should at least return `0` and the exception should be documented; returning `-1` is not a valid byte count and violates the documented contract.
## Impact
- Any user code or binding (e.g. the Python wrapper) that loads the `hash_table` implementation and checks `cs.getBytes() > 0` will incorrectly conclude the conflict set is empty.
- The returned value is silently incompatible with the documented semantics, making the hash_table implementation non-interchangeable with the other implementations for callers that inspect memory usage.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The
hash_tableshared-library implementation returns-1fromConflictSet::getBytes()andConflictSet_getBytes(), which contradicts the API contract documented ininclude/ConflictSet.hthat the function "Returns the total bytes in use by this ConflictSet".Location
HashTable.cpp:99—int64_t ConflictSet::getBytes() const { return -1; }HashTable.cpp:163-166—ConflictSet_getBytesalso hard-codes-1.Reproduction
build/hash_table/libconflict-set.so:Expected behavior
getBytes()should return a non-negative value representing the memory in use by the hash table implementation, consistent with the radix tree and skip list implementations. If tracking memory is intentionally not supported, the function should at least return0and the exception should be documented; returning-1is not a valid byte count and violates the documented contract.Impact
hash_tableimplementation and checkscs.getBytes() > 0will incorrectly conclude the conflict set is empty.Hash table is test only and does not satisfy the contract. It’s for comparing how fast point ops could be. Returning 0 for bytes used seems ok too