[improvement] aal and arch use long to represent the modification time of the file.

[ccodere]

The last modification date stored of an entry in the archive file in ar_date of ar_hdr is stored as a long value directly from the return result of the stat call. On POSIX systems, this should be fine, but could be an issue on non-POSIX systems as time_t could be represented as a non-integer type.

Some possible solutions:

• make a utility conversion routine in archiver.c of util/arch that uses struct tm to convert time_t from/to the ar_date format value. At the same time we could make ar_date unsigned long to give it a bigger range.

This not a big issue or high priority for now, but it has been added as a reference.

[kernigh]

There are multiple other problems:

• The ar_date has only 32 bits, will overflow in year 2038.
• The ar_uid and ar_gid have only 8 bits each. I am user id 1000, group id 1000, but my aal tv .../libc.a shows 232/232, because the low 8 bits of 1000 are 232.
• Filenames get truncated to 14 characters, so libmodula2.a contains "RealConversion" instead of "RealConversions.o".

To allow longer filenames, we might change the file format in an incompatible way. If so, it might be better to remove the date and uid/gid fields.

[davidgiven]

We've changed the object file format before (to add more relocation types), so I don't see a problem with changing the archive file format. I agree about the date and uid/gid fields --- who actually uses these? Other than shar, of course...