Open Hi-Angel opened 6 years ago
Yes, it doesn't handle duplicate erasure positions; good catch. This is inherited behaviour from the original Phil Karn implementation. I don't know if it's worthwhile sorting and uniquing the incoming erasure position vector; I think it should remain an error: the erasure positions should be unique. This should be documented.
I don't know if it's worthwhile sorting and uniquing the incoming erasure position vector; I think it should remain an error: the erasure positions should be unique. This should be documented.
Agree, sorting and uniquing would take unnecessary overhead, in this case it's better to leave to users. It's just that I thought it would come without the cost — like, restoring same position twice is the same as once. But granted, I don't know implementation details.
To be honest, in my case it revealed a bug. I imagine it could be nice to have the check, say, for debug mode only — just for a user to see they did something wrong. Otherwise all they see would be ezpwd failing to decode a block — "why? who knows".
Steps to reproduce
code:
building'n'running;
The reason for fail is duplicate erasure position
13, 13
, which is removed as part of the steps. I'm not sure if it's expected behavior.