kicad-developers team mailing list archive
Mailing list archive
Re: timestamp_t bit width
Am 2019-03-24 13:23, schrieb Jon Evans:
Another question from this forum thread:
timestamp_t is defined as "long", with a note that swig can't handle
I don't understand this comment. SWIG includes stdint.i which
explicitly defines the exact integral types. Maybe Jeff can shed some
This means that timestamp_t will be 32-bit on many platforms, but
64-bit on Linux and MacOS running on 64-bit hardware. Apparently
there is at least one bug here involving the Eagle importer writing
out library files with 64-bit timestamps, which 32-bit KiCad cannot
This is a problem in ParseHex(). If it gets a hex value that overflows,
it throws an error, stopping the processing. So this isn't specific to
the Eagle plugin but rather a 32-bit/64-bit issue. We allow 64-bit to
be written to file but only generate a time_t (32-bit) value for new,
The Eagle processor creates its own "timestamp" by hash which is 64 bits
on a 64 bit machine.
Q1: Is there actually a bug here? maybe someone more familiar with the
Eagle importer can take a look.
Yes. Definitely bug. We should be trimming the hash-based timestamp to
Q2: Shouldn't we change the type of timestamp_t to be either "int" (if
we want it to be 32-bit) or "long long" (if we want it to be 64-bit)?
I think 32-bits is the correct way to go here and using uint32_t should
work but I may be missing an important detail.
My first thought is that we should change timestamp_t to be 32-bit on
all platforms, but I'm not sure the best way to handle existing files
that have been written out with 64-bit timestamps.
This is problematic. I think we could patch the reader to handle 64-bit
values but store 32-bit.