kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

Am 2019-03-24 13:23, schrieb Jon Evans:
> Hi all,
>
> Another question from this forum thread:
> https://forum.kicad.info/t/before-giving-up-on-kicad-one-last-attempt-erc-misery/15933/67
>
> timestamp_t is defined as "long", with a note that swig can't handle
> int32_t.

I don't understand this comment.  SWIG includes stdint.i which 
explicitly defines the exact integral types.  Maybe Jeff can shed some 
light here?


> 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
> open.

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, 
internal stamps.

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 
32-bits.

> 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.

-Seth