Re: What happens to DEC Ada?

[Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

In article <nwya7.18388$MB7.4309099@nnrp1.proxad.net>, "nicolas" <n.brunot@cadwin.com> writes:
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> a �crit dans le
> message news: jGvPbYAYRtuu@eisner.encompasserve.org...
>> > Beside that, the timestamp method cannot always be trusted.
>> > We had problems with gnatmake which doesn't always recompile necessary
>> > files.
>> > The problem occurs when several files in different directories have same
>> > name, same timestamp, and are selected with ADA_INCLUDE_PATH
>> > timestamp and name of the file is checked, they are the sames, gnatmake
>> > doesn't figure out that this is a different file and doesn't recompile
> it.
>>
>> Well that sounds like just an implementation bug rather than a
>> conceptual flaw.
>>
> 
> We recompiled gnatmake with debug messages to see what went wrong actually.
> But I'm not sure you can call that an implementation bug.
> The flaw is to consider that 2 files with same name and same timestamp have
> the same content,
> or moreover that the content of a single  file has not changed, if the
> timestamp has not changed
> A lot of batch, or cvs import, commit or extractions, can generate a lot of
> files with same name and same timestamp.

But unless they are the same bits on the disk, they are a different
file.  On VMS you would use the 6 byte file ID and the 64 byte device
ID to determine uniqueness.  I am sure the same construct must exist
on other operating systems.

Granted, someone writing a tool may neglect to consider the situation
you describe, but that is still just an implementation bug.