Problems with SPARK_Mode

[Simon Wright]

I see a lot of problems using SPARK GPL 2015. For example, this (concocted from stm32f4-adc.ads and stm32f42xxx.ads) occurs frequently (there are others).

with System.Storage_Elements;
use System;
use type System.Storage_Elements.Storage_Offset;

package Access_To_Volatile with Spark_Mode is

   type Analog_To_Digital_Converter is limited record
      Dummy : Integer;
   end record
   with Volatile;

   type Analog_Input_Channel is mod 19;

   type ADC_Point is record
      ADC     : access Analog_To_Digital_Converter;
      Channel : Analog_Input_Channel;
   end record;

   VBat_Channel : constant Analog_Input_Channel := 18;

   Peripheral_Base : constant Address := System'To_Address (16#4000_0000#);
   APB2_Peripheral_Base : constant Address := Peripheral_Base + 16#0001_0000#;
   ADC1_Base   : constant Address := APB2_Peripheral_Base + 16#2000#;

   ADC_1 : aliased Analog_To_Digital_Converter
     with Volatile, Address => ADC1_Base;
   VBat : constant ADC_Point :=
     (ADC_1'Access, Channel => VBat_Channel);

end Access_To_Volatile;

results in

$ gnatprove -P sparking.gpr
Phase 1 of 2: generation of Global contracts ...
access_to_volatile.ads:28:07: volatile object cannot appear in this context (SPARK RM 7.1.3(13))
gnatprove: error during generation of Global contracts

I see you have some Codepeer constructs in bodies; is it that you don’t use SPARK, or is it that the GPL 2015 version has problems in this area? (I note that the error message is wrong, there is no (13) in the SPARK RM released with GPL 2015!)

[Fabien Chouteau]

Hello Simon,
This issue is not related to the driver repository.

Regards,

[Simon Wright]

So there is no point in opening the other issue I had in mind, which is that compiling with -gnaty results in many many style warnings?

You seem to be saying that this code isn’t intended to be compatible with formal methods?

[Fabien Chouteau]

Discussion about coding style for this repository is not a problem. I'm actually in favor of -gnaty. Let's see what the others think about it.

About formal methods, it is not a goal for this project at the moment. If you can make the drivers compatible without losing features and usability then please go ahead.

[Nicolas Setton]

FWIW I'm also in favor of -gnaty.

[Pat Rogers]

I am in favor of -gnaty except for the line-length restriction.

[Simon Wright]

I stick with the line-length restriction because I like to have two windows (Emacs frames) side-by-side. But that’s just my 2p.