CommandAPDU reuse data object to avoid PIN copy #80
Conversation
| } | ||
| insert(begin(), {cls, ins, p1, p2, static_cast<byte_type>(size())}); |
There was a problem hiding this comment.
Isn't it so that when using the T=0 protocol, the Le field should be omitted? Shouldn't you handle protocol differences here?
There was a problem hiding this comment.
We have many cases where we send with T=0 Le field and do not have any issues reported:
https://github.com/web-eid/libelectronic-id/blob/main/src/electronic-ids/pcsc/EIDIDEMIA.cpp#L146-L152
https://github.com/web-eid/libelectronic-id/blob/main/src/electronic-ids/pcsc/FinEID.cpp#L161-L162
If this is issue we should handle this in transfer()
There was a problem hiding this comment.
I would prefer that we test T=0 properly before merging.
metsma
force-pushed
the
apdu
branch
2 times, most recently
from
82eacfc to
6da3dc3
Compare
| if (d.size() > MAX_DATA_SIZE) { | ||
| throw std::invalid_argument("Command chaining and extended lenght not supported"); | ||
| } | ||
| d.insert(d.begin(), {cls, ins, p1, p2, static_cast<byte_type>(d.size())}); |
There was a problem hiding this comment.
insert() can cause a memory copy.
Let's use make_move_iterator for moving the data?
There was a problem hiding this comment.
how make_move_iterator avoids vector resize? it does same way resize to current vector and moves elements from one vector to other.
There was a problem hiding this comment.
make_move_iterator cannot avoid vector resize, but it can avoid a hidden memory copy if we allocate a sufficiently large target vector and move elements from the source vector to the target vector.
| @@ -47,24 +47,23 @@ inline pcsc_cpp::byte_vector addPaddingToPin(pcsc_cpp::byte_vector&& pin, size_t | |||
| pcsc_cpp::byte_type paddingChar) | |||
| { | |||
| pin.resize(std::max(pin.size(), paddingLength), paddingChar); | |||
| return pin; | |||
| return std::move(pin); | |||
There was a problem hiding this comment.
| return std::move(pin); | |
| return pin; |
This is not needed
There was a problem hiding this comment.
I disagree, see https://stackoverflow.com/a/14857144. When you have a function that takes an rvalue reference, modifies it, and then returns a copy of it, std::move() should be used as far as I understand. Yakk-Adam Nevraumont mentions that in C++20 the behavior changes, but I would like to see a specific reference and explanation of the new behavior.
pin is an lvalue within the function scope, even though it's an rvalue reference parameter. Returning an lvalue would typically invoke a copy - and yes, this may be elided with NRVO as you imply, but by explicitly applying std::move we can be sure that it is moved as intended and not rely on probable behavior.
There was a problem hiding this comment.
By the way, we should deal with the resize() problem here as well.
WE2-1007 Signed-off-by: Raul Metsma <[email protected]>
…error WE2-1007 Signed-off-by: Mart Somermaa <[email protected]>
WE2-1007 Signed-off-by: Mart Somermaa <[email protected]>
WE2-1007 Signed-off-by: Raul Metsma <[email protected]>
WE2-1007
Signed-off-by: Raul Metsma [email protected]