TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Fri, 5 May 2000 11:52:01 -0400
Reply-To: Michael Feldman <[log in to unmask]>
From: Michael Feldman <[log in to unmask]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]> from "W. Wesley Groleau x4923" at May 05, 2000 10:27:39 AM
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Parts/Attachments: text/plain (24 lines)
[said Wes]
>
> In other words, if it's important to you that a compiler support dates
> past 2038, your only assurance is the vendor's promise that their internal
> representation is immmune to any such "flaws" in the O.S.  (Or in some
> cases, personal inspection of the compiler source and/or the generated
> code.)
>
I cannot see how it's possible to immunize Ada completely. Obviously
a compiler developer can choose a representation for Ada.Calendar.Time
that is immune, and so with respect to time operations _within the
package_ there is no problem.

The glitch comes from talking to the world outside the package.
Unless I'm seriously off-base here, in implementing the function
Ada.Calendar.Clock, you can't read the clock without reading the
clock.

So you are, inherently, at the mercy of the underlying platform.
You might be able to end-run the _OS_ clock service and go straight
to the hardware clock, but suppose the hardware itself is noncompliant?

Mike Feldman

ATOM RSS1 RSS2