I am doing an automatic train protection on Ada with SPARK approach. This is my spec in SPARK:
package Sensors
--# own State,Pointer,State1,State2;
--# initializes State,Pointer,State1,State2;
is
type Sensor_Type is (Proceed, Caution, Danger, Undef);
subtype Sensor_Index_Type is Integer range 1..3;
procedure Write_Sensors(Value_1, Value_2, Value_3: in Sensor_Type);
--# global in out State,Pointer;
--# derives State from State,Value_1, Value_2, Value_3,Pointer &
--# Pointer from Pointer;
function Read_Sensor(Sensor_Index: in Sensor_Index_Type) return Sensor_Type;
function Read_Sensor_Majority return Sensor_Type;
end Sensors;
and this is my Ada:
package body Sensors is
type Vector is array(Sensor_Index_Type) of Sensor_Type;
State: Vector;
Pointer:Integer;
State1:Sensor_Type;
State2:Sensor_Type;
procedure Write_Sensors(Value_1, Value_2, Value_3: in Sensor_Type) is
begin
State(Pointer):=Value_1;
Pointer:= Pointer + 1;
State(Pointer):=Value_2;
Pointer:= Pointer + 1;
State(Pointer):=Value_3;
end Write_Sensors;
function Read_Sensor (Sensor_Index: in Sensor_Index_Type) return Sensor_Type
is
State1:Sensor_Type;
begin
State1:=Proceed;
if Sensor_Index=1 then
State1:=Proceed;
elsif Sensor_Index=2 then
State1:=Caution;
elsif Sensor_Index=3 then
State1:=Danger;
end if;
return State1;
end Read_Sensor;
function Read_Sensor_Majority return Sensor_Type is
State2:Sensor_Type;
begin
State2 := state(1);
return State2;
end Read_Sensor_Majority;
begin -- initialization
State:=Vector'(Sensor_Index_Type =>Proceed);
pointer:= 0;
State1:=Proceed;
State2:=Proceed;
end Sensors;
I want to know why in the function Read_Sensor_Majority I can't use the State(1) or any of the State() array values. If there is a way to use them, should I put anything in the specs of SPARK to make it happen?
The errors it's showing are:
1)Expression contains referenced to variable state which has an undefined value flow error 20
2)the variable state is nether imported nor defined flow error 32
3)the undefined initial value of state maybe used in the derivation of the function value flow error 602
You need to change the spec to read
function Read_Sensor_Majority return Sensor_Type;
--# global in State;
As I said in the comments above, I was puzzled by
State := Vector'(Sensor_Index_Type => Proceed);
but the compiler accepts it so it must be OK. And a little test shows that it has the same effect as
State := Vector'(others => Proceed);
Also pleased to report that the SPARK GPL 2011 toolset is now available for Mac OS X!
Heh. Well, those are definitely SPARK errors, rather than "garden variety" compiler errors.
It would be nice to see an actual cut-and-paste version of the errors (along with an indication of which lines they are referring to) rather than just an imperfect transcription. However, I do realise that isn't always possible for security/connectivity reasons.
It looks like all three are complaining about the flow of data through your system. Without knowing which lines they refer to, the best I can suggest is to try to manually trace your flow of data through your system to try to see what their problem is.
If I had to take a wild guess with the info I have here, I'd say it perhaps has a problem with your reading of a value from State(1) in the routine Read_Sensor_Majority, because it has no way of knowing that you've previously placed a value into that array location.
The code you have in the package's begin...end body area should take care of that, except it appears to have a compile error itself, as Simon pointed out in the comments. Perhaps if you fix that problem, SPARK will understand what is going on and quit complaining about your control flows.
If SPARK likes to spit out "I'm confused" errors on code that doesn't even get past the Ada compiler, it might be wise to make sure the Ada compiler likes the pure Ada part of your code before asking SPARK to look it over.
Related
I noticed that Rust does not have exceptions. How to do error handling in Rust and what are the common pitfalls? Are there ways to control flow with raise, catch, reraise and other stuff? I found inconsistent information on this.
Rust generally solves errors in two ways:
Unrecoverable errors. Once you panic!, that's it. Your program or thread aborts because it encounters something it can't solve and its invariants have been violated. E.g. if you find invalid sequences in what should be a UTF-8 string.
Recoverable errors. Also called failures in some documentation. Instead of panicking, you emit a Option<T> or Result<T, E>. In these cases, you have a choice between a valid value Some(T)/Ok(T) respectively or an invalid value None/Error(E). Generally None serves as a null replacement, showing that the value is missing.
Now comes the hard part. Application.
Unwrap
Sometimes dealing with an Option is a pain in the neck, and you are almost guaranteed to get a value and not an error.
In those cases it's perfectly fine to use unwrap. unwrap turns Some(e) and Ok(e) into e, otherwise it panics. Unwrap is a tool to turn your recoverable errors into unrecoverable.
if x.is_some() {
y = x.unwrap(); // perfectly safe, you just checked x is Some
}
Inside the if-block it's perfectly fine to unwrap since it should never panic because we've already checked that it is Some with x.is_some().
If you're writing a library, using unwrap is discouraged because when it panics the user cannot handle the error. Additionally, a future update may change the invariant. Imagine if the example above had if x.is_some() || always_return_true(). The invariant would changed, and unwrap could panic.
? operator / try! macro
What's the ? operator or the try! macro? A short explanation is that it either returns the value inside an Ok() or prematurely returns error.
Here is a simplified definition of what the operator or macro expand to:
macro_rules! try {
($e:expr) => (match $e {
Ok(val) => val,
Err(err) => return Err(err),
});
}
If you use it like this:
let x = File::create("my_file.txt")?;
let x = try!(File::create("my_file.txt"));
It will convert it into this:
let x = match File::create("my_file.txt") {
Ok(val) => val,
Err(err) => return Err(err),
};
The downside is that your functions now return Result.
Combinators
Option and Result have some convenience methods that allow chaining and dealing with errors in an understandable manner. Methods like and, and_then, or, or_else, ok_or, map_err, etc.
For example, you could have a default value in case your value is botched.
let x: Option<i32> = None;
let guaranteed_value = x.or(Some(3)); //it's Some(3)
Or if you want to turn your Option into a Result.
let x = Some("foo");
assert_eq!(x.ok_or("No value found"), Ok("foo"));
let x: Option<&str> = None;
assert_eq!(x.ok_or("No value found"), Err("No value found"));
This is just a brief skim of things you can do. For more explanation, check out:
http://blog.burntsushi.net/rust-error-handling/
https://doc.rust-lang.org/book/ch09-00-error-handling.html
http://lucumr.pocoo.org/2014/10/16/on-error-handling/
If you need to terminate some independent execution unit (a web request, a video frame processing, a GUI event, a source file to compile) but not all your application in completeness, there is a function std::panic::catch_unwind that invokes a closure, capturing the cause of an unwinding panic if one occurs.
let result = panic::catch_unwind(|| {
panic!("oh no!");
});
assert!(result.is_err());
I would not grant this closure write access to any variables that could outlive it, or any other otherwise global state.
The documentation also says the function also may not be able to catch some kinds of panic.
Reading through https://docs.perl6.org/language/packages#Package-qualified_names it outlines qualifying package variables with this syntax:
Foo::Bar::<$quux>; #..as an alternative to Foo::Bar::quux;
For reference the package structure used as the example in the document is:
class Foo {
sub zape () { say "zipi" }
class Bar {
method baz () { return 'Þor is mighty' }
our &zape = { "zipi" }; #this is the variable I want to resolve
our $quux = 42;
}
}
The same page states this style of qualification doesn't work to access &zape in the Foo::Bar package listed above:
(This does not work with the &zape variable)
Yet, if I try:
Foo::Bar::<&zape>; # instead of &Foo::Bar::zape;
it is resolves just fine.
Have I misinterpreted the document or completely missed the point being made? What would be the logic behind it 'not working' with code reference variables vs a scalar for example?
I'm not aware of differences, but Foo::Bar::<&zape> can also be modified to use {} instead of <>, which then can be used with something other than literals, like this:
my $name = '&zape';
Foo::Bar::{$name}()
or
my $name = 'zape';
&Foo::Bar::{$name}()
JJ and Moritz have provided useful answers.
This nanswer is a whole nother ball of wax. I've written and discarded several nanswers to your question over the last few days. None have been very useful. I'm not sure this is either but I've decided I've finally got a first version of something worth publishing, regardless of its current usefulness.
In this first installment my nanswer is just a series of observations and questions. I also hope to add an explanation of my observations based on what I glean from spelunking the compiler's code to understand what we see. (For now I've just written up the start of that process as the second half of this nanswer.)
Differences (if any) between Package::<&var> vs &Package::var?
They're fundamentally different syntax. They're not fully interchangeable in where you can write them. They result in different evaluations. Their result can be different things.
Let's step thru lots of variations drawing out the differences.
say Package::<&var>; # compile-time error: Undeclared name: Package
So, forget the ::<...> bit for a moment. P6 is looking at that Package bit and demanding that it be an already declared name. That seems simple enough.
say &Package::var; # (Any)
Quite a difference! For some reason, for this second syntax, P6 has no problem with those two arbitrary names (Package and var) not having been declared. Who knows what it's doing with the &. And why is it (Any) and not (Callable) or Nil?
Let's try declaring these things. First:
my Package::<&var> = { 42 } # compile-time error: Type 'Package' is not declared
OK. But if we declare Package things don't really improve:
package Package {}
my Package::<&var> = { 42 } # compile-time error: Malformed my
OK, start with a clean slate again, without the package declaration. What about the other syntax?:
my &Package::var = { 42 }
Yay. P6 accepts this code. Now, for the next few lines we'll assume the declaration above. What about:
say &Package::var(); # 42
\o/ So can we use the other syntax?:
say Package::<&var>(); # compile-time error: Undeclared name: Package
Nope. It seems like the my didn't declare a Package with a &var in it. Maybe it declared a &Package::var, where the :: just happens to be part of the name but isn't about packages? P6 supports a bunch of "pseudo" packages. One of them is LEXICAL:
say LEXICAL::; # PseudoStash.new(... &Package::var => (Callable) ...
Bingo. Or is it?
say LEXICAL::<&Package::var>(); # Cannot invoke this object
# (REPR: Uninstantiable; Callable)
What happened to our { 42 }?
Hmm. Let's start from a clean slate and create &Package::var in a completely different way:
package Package { our sub var { 99 } }
say &Package::var(); # 99
say Package::<&var>(); # 99
Wow. Now, assuming those lines above and trying to add more:
my Package::<&var> = { 42 } # Compile-time error: Malformed my
That was to be expected given our previous attempt above. What about:
my &Package::var = { 42 } # Cannot modify an immutable Sub (&var)
Is it all making sense now? ;)
Spelunking the compiler code, checking the grammar
1 I spent a long time trying to work out what the deal really is before looking at the source code of the Rakudo compiler. This is a footnote covering my initial compiler spelunking. I hope to continue it tomorrow and turn this nanswer into an answer this weekend.
The good news is it's just P6 code -- most of Rakudo is written in P6.
The bad news is knowing where to look. You might see the doc directory and then the compiler overview. But then you'll notice the overview doc has barely been touched since 2010! Don't bother. Perhaps Andrew Shitov's "internals" posts will help orient you? Moving on...
In this case what I am interested in is understanding the precise nature of the Package::<&var> and &Package::var forms of syntax. When I type "syntax" into GH's repo search field the second file listed is the Perl 6 Grammar. Bingo.
Now comes the ugly news. The Perl 6 Grammar file is 6K LOC and looks super intimidating. But I find it all makes sense when I keep my cool.
Next, I'm wondering what to search for on the page. :: nets 600+ matches. Hmm. ::< is just 1, but it is in an error message. But in what? In token morename. Looking at that I can see it's likely not relevant. But the '::' near the start of the token is just the ticket. Searching the page for '::' yields 10 matches. The first 4 (from the start of the file) are more error messages. The next two are in the above morename token. 4 matches left.
The next one appears a quarter way thru token term:sym<name>. A "name". .oO ( Undeclared name: Package So maybe this is relevant? )
Next, token typename. A "typename". .oO ( Type 'Package' is not declared So maybe this is relevant too? )
token methodop. Definitely not relevant.
Finally token infix:sym<?? !!>. Nope.
There are no differences between Package::<&var> and &Package::var.
package Foo { our $var = "Bar" };
say $Foo::var === Foo::<$var>; # OUTPUT: «True»
Ditto for subs (of course):
package Foo { our &zape = { "Bar" } };
say &Foo::zape === Foo::<&zape>;# OUTPUT: «True»
What the documentation (somewhat confusingly) is trying to say is that package-scope variables can only be accessed if declared using our. There are two zapes, one of them has got lexical scope (subs get lexical scope by default), so you can't access that one. I have raised this issue in the doc repo and will try to fix it as soon as possible.
I am trying to make a PE loader to understand more about Portable Executables. The thing I am stuck with is the processing of IAT. I am not able to understand what this piece of code does.
PIMAGE_THUNK_DATA nameRef = (PIMAGE_THUNK_DATA)((DWORD_PTR)dwMapBase + pImportDesc->Characteristics);
PIMAGE_THUNK_DATA symbolRef = (PIMAGE_THUNK_DATA)((DWORD_PTR)dwMapBase + pImportDesc->FirstThunk);
for (; nameRef->u1.AddressOfData; nameRef++, symbolRef++)
{
if (nameRef->u1.AddressOfData & 0x80000000)
{
symbolRef->u1.AddressOfData = (DWORD)GetProcAddress(hMod, MAKEINTRESOURCE(nameRef->u1.AddressOfData));
}
else
{
pImportName = (PIMAGE_IMPORT_BY_NAME)(dwMapBase + nameRef->u1.AddressOfData);
symbolRef->u1.Function = (DWORD)GetProcAddress(hMod, (LPCSTR)pImportName->Name);
}
}
I know that though Characteristics we identify the sections for giving the page READ, WRITE or EXECUTE permissions but nothing of that sort is happening here. By using some already existing codes I have written a PE loader but there is no error and the executable is not getting loaded. Just a hint in the right direction would be sufficient. Thanks.
PS code can be found here https://pastebin.com/0ZEn0i8k
Exactly that piece of code you've placed is intended to only one goal: resolve imports table, so each call to external function could be made with actual address of that imported function. You can take a look at this page to get more technical info: https://msdn.microsoft.com/en-us/library/ms809762.aspx
DWORD Characteristics
At one time, this may have been a set of flags. However, Microsoft changed its meaning and never bothered to update WINNT.H. This field is really an offset (an RVA) to an array of pointers. Each of these pointers points to an IMAGE_IMPORT_BY_NAME structure.
So, your snippet receives a pointer to array of import records as a nameRef variable. Then, each import can be one of possible modes:
Import by function ordinal number: this is where "if" takes place. Ordinals are always combined with 0x8000000 as user code is never mapped to such a high area. So, that "big eight" just says "this is not an address!".
Import by function name: this is "else" branch. Any non-zero AddressOfData below "big eight" points to an ASCII-Z string.
Zero - this is end-of-import table, dummy record.
And in both non-zero cases, GetProcAddress should resolve an import (by ordinal number or by name) to actual address in memory.
if you look for IMAGE_IMPORT_DESCRIPTOR definition, you can view that Characteristics is share union with OriginalFirstThunk. so really code can be written as
PIMAGE_THUNK_DATA nameRef = (PIMAGE_THUNK_DATA)
((DWORD_PTR)dwMapBase + pImportDesc->OriginalFirstThunk);
it will be the same effect. however this
(DWORD)GetProcAddress
does not cause you any questions ?
I am using the following code to filter a large array:
var arrayOfSelectedRowDetails = self.projectRowDetails.filter(
{ $0.projectNumber == self.projectNumberArray[selectedRow] }
)
Normally the code runs fine and I have no issues. But in one scenario (after I have deleted some management objects from the persistent store) and then rerun the code I am getting a EXC_BAD_ACCESS (code = 1, address=0x0) error at runtime.
I have set a break and stepped through the runtime of this statement. It is a large array built from a core data entity (using a fetch statement) - and therefore takes a long time. When I step through the code over the first dozen or so indexes the code runs ok - when i remove the break and let it run it then presents the error.
Is it possible to println() from within the closure statement to assist with debugging? I have tried a number of different syntaxes and cannot get it to work.
Alternatively, is it possible to set an error capture statement within the closure so that the code ceases through a break or an abort() statement?
Fundamentally i am trying to identify the index of the array at the point that the error occurs so that I can get sufficient information to debug the delete function (which is where I think the error is). I do not seem to be able to ascertain the index from the info available to me when the error occurs.
This is the first time I have tried programming in Swift and making use of closures so I am learning as I go. Apologies if I am asking fundamental questions. I have not been able to find a similar question elsewhere here with an answer that works.
You can set an exception breakpoint in Xcode (for an example see here).
Also, I suggest that you move the access to self.projectNumberArray out of the closure:
let pn = self.projectNumberArray[selectedRow]
var arrayOfSelectedRowDetails = self.projectRowDetails.filter(
{ $0.projectNumber == pn }
)
The change might not solve the issue, but it will at least help the debugging.
Lastly, if you want to print the index, the following approach will probably work:
let pn = self.projectNumberArray[selectedRow]
var index = 0
var arrayOfSelectedRowDetails = self.projectRowDetails.filter(
{ println(index++); return $0.projectNumber == pn }
)
I'm using GNAT GPS studio IDE in order to train a bit in Ada. I'm having an issue with package visibility.
First I specify a package in a file called "DScale.ads" containing a type:
package DScale is
type DMajor is (D, E, F_Sharp, G, A, B, C_Sharp);
end DScale;
Then I specify in a different file ("Noteworthy.ads") a package that defines a procedure that will use the DMajor type of the DScale package:
with Ada.Text_IO;
with DScale;
package NoteWorthy is
procedure Note;
end NoteWorthy;
Finally in "Noteworthy.adb" I provide the package body for the package "Noteworthy":
with Ada.Text_IO; use Ada.Text_IO;
package body Noteworthy is
procedure Note is
package ScaleIO is new Enumeration_IO(DScale.DMajor);
thisNote : DScale.DMajor := DScale.D;
begin
ScaleIO.Get(thisNote);
if thisNote = DScale.DMajor'First then
Put_Line("First note of scale.");
end if;
end Note;
begin
null;
end NoteWorthy;
If I leave the code as-is, I will get an "operator not directly visible" error for the "if thisNote = DScale.DMajor'First then" statement in the body of the "Noteworthy" package.
Is there a way to bypass this error without using a "use" or "use type" clause?
Thank you.
There are (at least) two answers to your question.
1:
if DScale."=" (thisNote, DScale.DMajor'First) then
2:
function "=" (Left, Right : DScale.DMajor) return Boolean renames DScale.DMajor;
...
if thisNote = DScale.DMajor'First then
But why would you use one of those options instead of:
use type DScale.DMajor;
...
if thisNote = DScale.DMajor'First then
Ada types are much more than just descriptions of the values, they are entities that bring into existence a whole slew of operations, embodied as both operators and attributes. So if you want direct visibility to a type's concrete "=" operator, you have to make it visible. For that you need either "use" or "use type".
Why bypass a language feature? Simply use it wisely.
A couple of points that are related to the structure of your code.
The package spec for Noteworthy doesn't need to "with DScale" as there is nothing in the spec that refers to any feature in that package (maybe you plan to in the future).
The use of enumeration_io is good if you want to simply want to do I/O to files to be read by a computer, but I would never use it for human interaction (apart from quick hacks). The input values it accepts is dictated by Ada's grammar, and typically not what user's expect.