[SERVER-4357] Missing appender for uint64_t in BSONObjBuilder Created: 23/Nov/11 Updated: 11/Jul/16 Resolved: 29/Nov/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Hillel Lubman | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 0 |
| Labels: | stdint, uint64_t | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux x86_64 / g++ |
||
| Backwards Compatibility: | Minor Change |
| Operating System: | Linux |
| Participants: |
| Description |
|
Compilation fails on BSONObjBuilder when one of the arguments is of uint64_t type. Example: uint64_t val; Error produced: <...>/mongo/client/../util/net/../../db/../bson/bson-inl.h: In member function 'mongo::BSONObjBuilder& mongo::BSONObjBuilderValueStream::operator<<(T) [with T = long unsigned int]': |
| Comments |
| Comment by Mathias Stearn [ 18/Jan/12 ] |
|
https://github.com/mongodb/mongo/commit/cb41d6515b220a4967331eeb873891dd33f590bb |
| Comment by Mathias Stearn [ 29/Nov/11 ] |
|
Backward breaking only cases that didn't work correctly before. |
| Comment by Mathias Stearn [ 28/Nov/11 ] |
|
We don't really support unsigned ints as we don't have a special type for them. In particular it is not possible to store the full range of values in an unsigned 64-bit int. In the uint32_t case it looks like either it is being silently converted to a signed 32 bit int or it is being converted to a 64-bit int with sign-extending. If you print out b.firstElement().type() it will make it clear which case it is. I think the real solution is to make two private overloads for uint32_t and uint64_t to make it clear that they aren't supported and to prevent compilation when their use is attempted. |
| Comment by Hillel Lubman [ 23/Nov/11 ] |
|
Something wrong is happening with uint32_t type as well. Simple test: uint32_t val = 3327489326; Produces: { "key" : -967477970 }Which is incorrect (Linux, x86_64, g++). |