View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008071 | Taler | exchange | public | 2024-01-11 17:46 | 2024-03-07 19:47 |
| Reporter | fefe | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | trivial | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0008071: TALER_denom_ewv_deep_copy does not actually do a deep copy | ||||
| Description | This is in exchange/src/util/denom.c: 254 void 255 TALER_denom_ewv_deep_copy (struct TALER_ExchangeWithdrawValues *bi_dst, 256 const struct TALER_ExchangeWithdrawValues *bi_src) 257 { 258 if (bi_src == TALER_denom_ewv_rsa_singleton ()) 259 { 260 *bi_dst = *bi_src; 261 return; 262 } 263 bi_dst->blinding_inputs 264 = GNUNET_CRYPTO_blinding_input_values_incref (bi_src->blinding_inputs); 265 } Not sure if this is of any significance in practice, but if the function is called deep_copy you might expect that it actually does a deep copy. | ||||
| Tags | No tags attached. | ||||
| Other deep_copy functions in the same file also don't do a deep copy. | |
| These are really read-only objects, so the bug is sure to have zero impact modulo code comprehension. Using _incref instead of _deep_copy isn't exactly correct; I guess _copy might be OK, any better ideas? | |
| I think both _incref and _copy would work better than _deep_copy. Why would _incref not be correct? | |
| Well, it does an incref internally while copying into a new struct, but the outer struct we copy to doesn't have a reference counter. So incref on an object that doesn't have an RC itself seems, well, also confusing? | |
| Anyway, if _copy is fine for you, i'll kill the _deep and consider this done. | |
| exchange.git: fix in 6bfc96f4c..ec522a445 merchnat.git: fix in 4c1ed87d..537bb34b | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-01-11 17:46 | fefe | New Issue | |
| 2024-01-11 17:46 | fefe | Status | new => assigned |
| 2024-01-11 17:46 | fefe | Assigned To | => Christian Grothoff |
| 2024-01-11 17:47 | fefe | Note Added: 0020864 | |
| 2024-01-11 17:51 | Christian Grothoff | Note Added: 0020865 | |
| 2024-01-11 17:51 | Christian Grothoff | Severity | minor => trivial |
| 2024-01-11 17:51 | Christian Grothoff | Product Version | => git (master) |
| 2024-01-15 18:44 | Florian Dold | Target Version | => 1.0 |
| 2024-01-16 12:33 | Christian Grothoff | Assigned To | Christian Grothoff => fefe |
| 2024-01-16 12:33 | Christian Grothoff | Status | assigned => feedback |
| 2024-01-16 13:18 | fefe | Note Added: 0020891 | |
| 2024-01-16 13:19 | Christian Grothoff | Note Added: 0020892 | |
| 2024-01-16 13:21 | Christian Grothoff | Note Added: 0020893 | |
| 2024-01-16 13:46 | Christian Grothoff | Note Added: 0020894 | |
| 2024-01-16 13:46 | Christian Grothoff | Status | feedback => informing |
| 2024-01-16 13:46 | Christian Grothoff | Resolution | open => fixed |
| 2024-01-16 13:46 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-01-16 13:46 | Christian Grothoff | Assigned To | fefe => Christian Grothoff |
| 2024-01-16 13:46 | Christian Grothoff | Target Version | 1.0 => 0.9.4 |
| 2024-01-18 22:32 | Christian Grothoff | Relationship added | child of 0008112 |
| 2024-03-07 19:47 | Christian Grothoff | Status | informing => closed |