Re: NVRAM or how can I enforce a range check in Ada83.

Re: NVRAM or how can I enforce a range check in Ada83.

[Stephen Leake]

Peter Vogelsanger wrote:
> 
> Hello Ada people (or fans ;-))
> 
> We are useing a Non Volatile RAM (EEPROM) in our project. The NVRAM driver
> accesses the hardware by word operations. Now we've programmed a generic driver
> which transform the generic type to a byte or word array. Because of the
> possibility of an hardware error, we have to check the read values from the
> NVRAM. We use an unchecked_conversion to transform from byte array to the
> generic type. We have got no informations about the type inside this generic
> procedure.
> 
> Code:
> 
>   generic
>      type Elements is private;
>   procedure Read (Item : out Elements);
> 
>   procedure Read (Item : out Elements) is
>      function Convert is new Unchecked_Conversion (Source => <<byte array>>,
>                                                    Target => Elements);
>   begin
>      Item := Convert (<<Nvram_Byte_Array_Of_Element_Size>>);
>   end Read;
> 
> The Unchecked_Conversion does not make any checks, therefore the name unchecked.
> [snip] 
> Now is there a construct that enforce the compiler to make a range check? But
> remember in this generic procedure we haven't got any type information.
> Also important: we use Ada83.
> 

Apparently you want to validate the data before converting returning it?

One way is to add a Validate function to the generic interface:

   generic
      type Elements is private;
      with function Validate (Item : in Elements; Data : in Byte_Array) 
	return Boolean;
   procedure Read (Item : out Elements);

Where Byte_Array is the "raw" data. Validate should do whatever checks
are appropriate to the type, and return True if it's ok.

This makes Read much more powerful, but much less abstract.

Another way is provide a Checked_Conversion for each scalar type that
might be used in Elements, and let the user write a higher-level
Checked_Conversion. Depends on what sort of checks you want to perform.

> Peter
> >

-- 
- Stephe

NVRAM or how can I enforce a range check in Ada83.

[Peter Vogelsanger]

Hello Ada people (or fans ;-))

We are useing a Non Volatile RAM (EEPROM) in our project. The NVRAM driver
accesses the hardware by word operations. Now we've programmed a generic driver
which transform the generic type to a byte or word array. Because of the
possibility of an hardware error, we have to check the read values from the
NVRAM. We use an unchecked_conversion to transform from byte array to the
generic type. We have got no informations about the type inside this generic
procedure.

Code:

  generic
     type Elements is private;
  procedure Read (Item : out Elements);

  procedure Read (Item : out Elements) is
     function Convert is new Unchecked_Conversion (Source => <<byte array>>,
                                                   Target => Elements);
  begin
     Item := Convert (<<Nvram_Byte_Array_Of_Element_Size>>);
  end Read;

The Unchecked_Conversion does not make any checks, therefore the name unchecked.
We've tried to use a temporary variable to assigne the unchecked_converion
value and then assigne our parameter with this temporary variable and hoped
that a check would be performed.

   begin
     Temp := Convert(<<Nvram_Byte_Array_Of_Element_Size>>);
     Item := Temp;
   exception
     when constraint_error =>
         << some critical action>>
   end Read;

But as I've read later the Reference Manual, I've seen that no range check are
done by an assignment.

Now is there a construct that enforce the compiler to make a range check? But
remember in this generic procedure we haven't got any type information.
Also important: we use Ada83.

Has somebody any idea about this problem?

Best Regards

Peter
>

Re: NVRAM or how can I enforce a range check in Ada83.

[Ken Garlington]

Peter Vogelsanger wrote:
> 
> Hello Ada people (or fans ;-))
> 
> We are useing a Non Volatile RAM (EEPROM) in our project. The NVRAM driver
> accesses the hardware by word operations. Now we've programmed a generic driver
> which transform the generic type to a byte or word array. Because of the
> possibility of an hardware error, we have to check the read values from the
> NVRAM. We use an unchecked_conversion to transform from byte array to the
> generic type. We have got no informations about the type inside this generic
> procedure.
> 
> Code:
> 
>   generic
>      type Elements is private;
>   procedure Read (Item : out Elements);
> 
>   procedure Read (Item : out Elements) is
>      function Convert is new Unchecked_Conversion (Source => <<byte array>>,
>                                                    Target => Elements);
>   begin
>      Item := Convert (<<Nvram_Byte_Array_Of_Element_Size>>);
>   end Read;
> 
> The Unchecked_Conversion does not make any checks, therefore the name unchecked.
> We've tried to use a temporary variable to assigne the unchecked_converion
> value and then assigne our parameter with this temporary variable and hoped
> that a check would be performed.
> 
>    begin
>      Temp := Convert(<<Nvram_Byte_Array_Of_Element_Size>>);
>      Item := Temp;
>    exception
>      when constraint_error =>
>          << some critical action>>
>    end Read;
> 
> But as I've read later the Reference Manual, I've seen that no range check are
> done by an assignment.
> 
> Now is there a construct that enforce the compiler to make a range check? But
> remember in this generic procedure we haven't got any type information.
> Also important: we use Ada83.

Since the type you're passing in might be a composite type, there's no way
realistically for the compiler to enforce a "range check", since such types
don't really have such a thing (although their components might).

There is an Ada 83 interpretation that says compilers are permitted to warn
you if the Source and Target are of different sizes on an unchecked conversion,
but as I understand it this isn't a requirement.

(By the way, how do you know how big to make your byte/word array?)

Best answer, as far as I can tell, is the user-written Validate procedure
suggested previously.

> 
> Has somebody any idea about this problem?
> 
> Best Regards
> 
> Peter
> >

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: NVRAM or how can I enforce a range check in Ada83.

[Robert Dewar]

Ken Garlington says

"There is an Ada 83 interpretation that says compilers are permitted to warn
you if the Source and Target are of different sizes on an unchecked conversion,
but as I understand it this isn't a requirement."

This is not right. No interpretation is needed to permit a compiler to 
generate warning messages, a compiler can generate whatever warning
messages it likes, since these are entirely outside the language.

As for requirements, there is not even a requirement that error messages
be generated for illegal programs, since again messages are entirely outside
the language definition. The only semantic requirement is that the library
(Ada 83) or compilation environment (Ada 95) not be affected by compiling
an illegal unit.

Re: NVRAM or how can I enforce a range check in Ada83.

[Robert A Duff]

In article <dewar.848229223@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>As for requirements, there is not even a requirement that error messages
>be generated for illegal programs, since again messages are entirely outside
>the language definition. ...

This is not right.  1.1.3(1,4) say, "A conforming implementation shall
... Identify all programs or program units that contain errors ...".
Well, to me, that seems to imply that the implementation has to give
some indication on errors -- I would call that an "error message".

Of course, there is no requirement that the error message be useful.  It
could say, "This program is illegal."  (It would be friendlier to say
why, and give a line number or something.)  It could even just "beep" to
indicate an error.  But if the implementation were completely silent
about errors -- i.e. gave identical output for errors and non-errors, I
would say that clearly violates the above requirement.

>... The only semantic requirement is that the library
>(Ada 83) or compilation environment (Ada 95) not be affected by compiling
>an illegal unit.

Not true for Ada 95.  In Ada 95 it *is* permissible for the compilation
of an illegal compilation unit to affect the compilation environment.
The only requirement is that you can't run an illegal or inconsistent
partition.

- Bob

Re: NVRAM or how can I enforce a range check in Ada83.

[Robert Dewar]

Bob Duff said

"This is not right.  1.1.3(1,4) say, "A conforming implementation shall
... Identify all programs or program units that contain errors ...".
Well, to me, that seems to imply that the implementation has to give
some indication on errors -- I would call that an "error message"."


identify = some indication of an error = pretty vague.

For example, a compiler is conforming if it says the following:

In accordance with 1.1.3(1,4), this compiler identifies program units
that contain errors by not generating an object file for any such units.

Re: NVRAM or how can I enforce a range check in Ada83.

[Robert A Duff]

In article <dewar.848351899@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>In accordance with 1.1.3(1,4), this compiler identifies program units
>that contain errors by not generating an object file for any such units.

Yeah, but GNAT would have to be substantially redesigned to support this
feature, since it doesn't generate object files for some legal files.

;-)

- Bob

Re: NVRAM or how can I enforce a range check in Ada83.

[Laurent Guerby]

Robert> identify = some indication of an error = pretty vague.

Robert> For example, a compiler is conforming if it says the
Robert> following:

Robert> In accordance with 1.1.3(1,4), this compiler identifies
Robert> program units that contain errors by not generating an object
Robert> file for any such units.

   This is one point where the ACVC (I'm thinking about the B tests)
can be see as very positive.  A vendor whose compiler intends to play
this game ("unit blah is legal/illegal, thank you good bye.")  will
have to face a huge paperwork effort (more than 1000 B tests with may
be 10 or more errors per test = 10_000 splits, forget it). Worth
producing some error messages near where the "-- ERROR" are ;-).

   I've never heard complaints about Ada compiler error messages (as
opposed to code quality or bugs) and ACVC B tests might not be foreign
to that. Think about the average C compiler error messages ...

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: NVRAM or how can I enforce a range check in Ada83.

[Robert Dewar]

Ken says

"Robert Dewar wrote:
>
> Ken Garlington says
>
> "There is an Ada 83 interpretation that says compilers are permitted to warn
> you if the Source and Target are of different sizes on an unchecked conversion
,
> but as I understand it this isn't a requirement."
>
> This is not right. No interpretation is needed to permit a compiler to
> generate warning messages, a compiler can generate whatever warning
> messages it likes, since these are entirely outside the language.

There is an Ada 83 AI that includes these words. It may not be a well-written AI
,
but it does exist. My browser is behaving badly at the moment, but perhaps you
could go look at the Ada 83 AI written about Unchecked_Conversions between sourc
e
and target of different sizes, and explain where I misunderstood the words."



This might well be mentioned in an AI, but is not part of the interpretation,
just a useful reminder to the reader that compilers are ALWAYS allowed
to generate warnings about anything that they want. An AI might often
point out that it is quite reasonable to issue a warning in some given
situation, but in no sense is the AI *granting* that permissing, which
always exists, regardless of any AI's.

Re: NVRAM or how can I enforce a range check in Ada83.

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken Garlington says
> 
> "There is an Ada 83 interpretation that says compilers are permitted to warn
> you if the Source and Target are of different sizes on an unchecked conversion,
> but as I understand it this isn't a requirement."
> 
> This is not right. No interpretation is needed to permit a compiler to
> generate warning messages, a compiler can generate whatever warning
> messages it likes, since these are entirely outside the language.

There is an Ada 83 AI that includes these words. It may not be a well-written AI,
but it does exist. My browser is behaving badly at the moment, but perhaps you 
could go look at the Ada 83 AI written about Unchecked_Conversions between source
and target of different sizes, and explain where I misunderstood the words.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: NVRAM or how can I enforce a range check in Ada83.

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken says
> 
> "Robert Dewar wrote:
> >
> > Ken Garlington says
> >
> > "There is an Ada 83 interpretation that says compilers are permitted to warn
> > you if the Source and Target are of different sizes on an unchecked conversion
> ,
> > but as I understand it this isn't a requirement."
> >
> > This is not right. No interpretation is needed to permit a compiler to
> > generate warning messages, a compiler can generate whatever warning
> > messages it likes, since these are entirely outside the language.
> 
> There is an Ada 83 AI that includes these words. It may not be a well-written AI
> ,
> but it does exist. My browser is behaving badly at the moment, but perhaps you
> could go look at the Ada 83 AI written about Unchecked_Conversions between sourc
> e
> and target of different sizes, and explain where I misunderstood the words."
> 
> This might well be mentioned in an AI, but is not part of the interpretation,
> just a useful reminder to the reader that compilers are ALWAYS allowed
> to generate warnings about anything that they want. An AI might often
> point out that it is quite reasonable to issue a warning in some given
> situation, but in no sense is the AI *granting* that permissing, which
> always exists, regardless of any AI's.

So my original statement is correct: There is an AI that does say: "compilers are
permitted to warn you if the Source and Target are of different sizes on an unchecked 
conversion". If the compiler is permitted to generate ANY warning, then it should be
permitted to generate this warning, right?

The more important part of the statement, of course, is that the compiler is not
_required_ to generate such a warning.


-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com