Opened 11 years ago
Last modified 11 years ago
#350 assigned task
Refactor GB_write_int and dependents to use int32_t
Reported by: | epruesse | Owned by: | epruesse |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | global | Version: | SVN |
Keywords: | Cc: |
Description (last modified by epruesse)
It's not int nor long but int32_t due to on disk database format.
Change History (6)
comment:1 Changed 11 years ago by epruesse
- Owner changed from devel to epruesse
- Status changed from new to assigned
comment:2 Changed 11 years ago by westram
comment:3 follow-up: ↓ 4 Changed 11 years ago by epruesse
So we should really make it int throughout ARB?
comment:4 in reply to: ↑ 3 Changed 11 years ago by westram
Replying to epruesse:
So we should really make it int throughout ARB?
Not int, int32_t!
int may be any size.
I think we do not have any choice w/o changing the binary format, at least for all things mapped somehow to the .
comment:5 Changed 11 years ago by epruesse
- Component changed from Library (GUI) to global
- Description modified (diff)
- Summary changed from AW_scalar uses int32_t, AW_awar uses long int -- syncronise to Refactor GB_write_int and dependents to use int32_t
- Version changed from gtkport to SVN
comment:6 Changed 11 years ago by epruesse
- Priority changed from normal to minor
Note: See
TracTickets for help on using
tickets.
Be aware: int-awars are based on GB_write_int, which uses a long as parameter (because it was not fixed yet), but internally it checks against 32-bit overflow. This cannot change, since we need to keep DBs binary-compatible.
Therefore int32_t is the wanted type