Test for constant (or "in parameter" in procedure)

Test for constant (or "in parameter" in procedure)

[reinkor]

Hi,

is it a good way to test if an object is a constant or not (or "in parameter" in a procedure)? Something in addition to declare it as a constant?

If I am sure an object is a constant (and can check it) then this can sometimes help to structure/optimize the code. I would like to have some redundancy and make sure an object is really constant when this is a prerequisite for a piece of code to be according to my intentions - i.e. if the object is messed with somewhere, then things could go wrong. So I would like some "local check" to be sure a constant is really a constant :-) Specially if many people are involved to change code over time.

reinert

Re: Test for constant (or "in parameter" in procedure)

[AdaMagica]

What do you mean by testing for constantness?
An object is either declared constant or not; it's either an in-parameter or not.

But be careful: Especially for immutably limited types, you cannot (and need not) know what's going on behind the screen.

(E.g. what would a constant task object mean? And think of the Rosen trick!)

It's completely up to the implementor of an immutably limited object to behave correctly under all circumstances. You, the user, cannot know whether it's truely constant or not.

Re: Test for constant (or "in parameter" in procedure)

[reinkor]

OK, I here try to communicate my intention via this simple example:

i : Constant Integer := 5; -- all OK so far (but someone could 
                               change this to a variable)

begin

.... some code ...

if "i is not constant (cannot change value)" then
   Some_error_handling;
end if;

(or alternatively error message/warning at compilation)

Re: Test for constant (or "in parameter" in procedure)

[Dmitry A. Kazakov]

On 09/02/2017 13:46, reinkor wrote:
> OK, I here try to communicate my intention via this simple example:
>
> i : Constant Integer := 5; -- all OK so far (but someone could
>                                change this to a variable)
>
> begin
>
> .... some code ...
>
> if "i is not constant (cannot change value)" then
>    Some_error_handling;
> end if;

i cannot change its value all its life time. This is regardless how its 
initial value was obtained.

> (or alternatively error message/warning at compilation)

Maybe we could help better if you tell us what the original problem is.

If you consider this:

loop
    declare
       I : constant Integer := Read_From_File;
    begin
       ...
    end;
end loop;

It would be meaningless to ask if I changes its value. There are many 
I's all unrelated to each other. If you want to relate them, you must 
move the declaration of I to the least common scope, e.g. like this:

declare
    I : Integer; -- Now it is only one I for each iteration
begin
    loop
       I := Read_From_File;
       ...
    end loop;
end;

You can immediately see that I is not a constant. And you could not make 
it constant.

As it was said, it is either constant (immutable) or not (mutable). Your 
very question is meaningless.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Test for constant (or "in parameter" in procedure)

[AdaMagica]

Am Donnerstag, 9. Februar 2017 13:46:45 UTC+1 schrieb reinkor:
> OK, I here try to communicate my intention via this simple example:
> 
> i : Constant Integer := 5; -- all OK so far (but someone could 
>                                change this to a variable)

You mean, someone later removes the constant keyword?

Well, now, against what stupidities do you want to make your code safe?
There will always be some who know what they do and others who don't.

Re: Test for constant (or "in parameter" in procedure)

[reinkor]

On Thursday, February 9, 2017 at 3:10:57 PM UTC+1, AdaMagica wrote:
> Am Donnerstag, 9. Februar 2017 13:46:45 UTC+1 schrieb reinkor:
> > OK, I here try to communicate my intention via this simple example:
> > 
> > i : Constant Integer := 5; -- all OK so far (but someone could 
> >                                change this to a variable)
> 
> You mean, someone later removes the constant keyword?
> 

Bingo ! (and assume the code is somehow complex and I is set in another package)

Re: Test for constant (or "in parameter" in procedure)

[G.B.]

On 09.02.17 13:46, reinkor wrote:
> OK, I here try to communicate my intention via this simple example:
>
> i : Constant Integer := 5; -- all OK so far (but someone could
>                                change this to a variable)
>

You could try making it more difficult for programmers
you seemingly need to fight in source text by

- by making i a function; hide its body,
- make your code depend on compile time static constants.

I'd suggest that it is time, technically, for your boss
or for yourself to call for discipline, or ask you lawyer
about what your contracts require you to guarantee if
someone changes i to be some kind of constness backdoor.

Re: Test for constant (or "in parameter" in procedure)

[reinkor]

On Thursday, February 9, 2017 at 5:51:46 PM UTC+1, G.B. wrote:
> On 09.02.17 13:46, reinkor wrote:
> > OK, I here try to communicate my intention via this simple example:
> >
> > i : Constant Integer := 5; -- all OK so far (but someone could
> >                                change this to a variable)
> >
> 
> You could try making it more difficult for programmers
> you seemingly need to fight in source text by
> 
> - by making i a function; hide its body,
> - make your code depend on compile time static constants.
> 
> I'd suggest that it is time, technically, for your boss
> or for yourself to call for discipline, or ask you lawyer
> about what your contracts require you to guarantee if
> someone changes i to be some kind of constness backdoor.

Maybe SPARK has an answer.

Re: Test for constant (or "in parameter" in procedure)

[Dmitry A. Kazakov]

On 2017-02-09 17:59, reinkor wrote:
> On Thursday, February 9, 2017 at 5:51:46 PM UTC+1, G.B. wrote:
>> On 09.02.17 13:46, reinkor wrote:
>>> OK, I here try to communicate my intention via this simple example:
>>>
>>> i : Constant Integer := 5; -- all OK so far (but someone could
>>>                                change this to a variable)
>>>
>>
>> You could try making it more difficult for programmers
>> you seemingly need to fight in source text by
>>
>> - by making i a function; hide its body,
>> - make your code depend on compile time static constants.
>>
>> I'd suggest that it is time, technically, for your boss
>> or for yourself to call for discipline, or ask you lawyer
>> about what your contracts require you to guarantee if
>> someone changes i to be some kind of constness backdoor.
>
> Maybe SPARK has an answer.

Rather the OS. Set the ads file read-only. Calculate its signature (of 
military-grade length). Store the signature on an encrypted flash drive 
protected by biometric scanner. Verify the signature each 5 seconds to 
detect malicious source code modifications by intruders...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Test for constant (or "in parameter" in procedure)

[G.B.]

On 09.02.17 18:17, Dmitry A. Kazakov wrote:
>> Maybe SPARK has an answer.
>
> Rather the OS. Set the ads file read-only. Calculate its signature (of military-grade length). Store the signature on an encrypted flash drive protected by biometric scanner. Verify the signature each 5 seconds to detect malicious source code modifications by intruders...


Alternatively, you could store each line of source text
in a DBMS that offers access control to rows, or if each
spec lives in a separate table, to tables, etc.
Then, have rights grated to team members accordingly.

If working on Windows™, the object based UAC system could
be used for associating rights with file objects, per user.

Re: Test for constant (or "in parameter" in procedure)

[Niklas Holsti]

On 17-02-09 18:51 , G.B. wrote:
> On 09.02.17 13:46, reinkor wrote:
>> OK, I here try to communicate my intention via this simple example:
>>
>> i : Constant Integer := 5; -- all OK so far (but someone could
>>                                change this to a variable)
>>
>
> You could try making it more difficult for programmers
> you seemingly need to fight in source text by
>
> - by making i a function; hide its body,
> - make your code depend on compile time static constants.
>
> I'd suggest that it is time, technically, for your boss
> or for yourself to call for discipline, or ask you lawyer
> about what your contracts require you to guarantee if
> someone changes i to be some kind of constness backdoor.

I think I see a valid point in the OP's question. One can imagine a 
program in which a package A supplies a value ("i" in the example), and 
in which another, loosely related package B, perhaps in quite another 
part of the program, implements an algorithm that logically depends on 
this value never changing (after elaboration). It would be nice to be 
able to express this inter-package constancy constraint somehow, at 
compile time, as a guard against future mistakes in program evolution 
that might make the value non-constant and so destroy the logical basis 
for the algorithm in package B.

At present, it seems to me that Ada offers only two ways to do this.

The first way is to make the constant a named number in A, or a constant 
with a static value, and make a copy as a named number in B. Like this:

    package A is
       I : constant Integer := 5;
       -- A named number or (as here) a constant with a static value.
    end A;

    with A;
    package B is
       My_I : constant := A.I;
       -- A named number. This does not compile if A.I is non-constant,
       -- or has a non-static value (even if constant).
    end B;

However, this only works if the type of the constant is numeric.

The second way is just to document the reasons for the object being 
declared constant, at the point of that declaration:

    package A is
       I : constant Integer := 5;
       -- This must be a constant, because package B etc. etc.
    end A;

I see less reason for a run-time check of constancy. However, there is a 
similar thing in Ada: the attribute 'Constrained. Perhaps there would be 
some interest in an attribute 'Constant, which could be applied to any 
object or named number and would be True for named numbers and constant 
objects, and only for those. On first look, it seems very simple to 
implement (but perhaps there is some complication in shared-code 
generics...)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Test for constant (or "in parameter" in procedure)

[reinkor]

You saved me :-)  

reinert

On Thursday, February 9, 2017 at 7:46:03 PM UTC+1, Niklas Holsti wrote:
> On 17-02-09 18:51 , G.B. wrote:
> > On 09.02.17 13:46, reinkor wrote:
> >> OK, I here try to communicate my intention via this simple example:
> >>
> >> i : Constant Integer := 5; -- all OK so far (but someone could
> >>                                change this to a variable)
> >>
> >
> > You could try making it more difficult for programmers
> > you seemingly need to fight in source text by
> >
> > - by making i a function; hide its body,
> > - make your code depend on compile time static constants.
> >
> > I'd suggest that it is time, technically, for your boss
> > or for yourself to call for discipline, or ask you lawyer
> > about what your contracts require you to guarantee if
> > someone changes i to be some kind of constness backdoor.
> 
> I think I see a valid point in the OP's question. One can imagine a 
> program in which a package A supplies a value ("i" in the example), and 
> in which another, loosely related package B, perhaps in quite another 
> part of the program, implements an algorithm that logically depends on 
> this value never changing (after elaboration). It would be nice to be 
> able to express this inter-package constancy constraint somehow, at 
> compile time, as a guard against future mistakes in program evolution 
> that might make the value non-constant and so destroy the logical basis 
> for the algorithm in package B.
> 
> At present, it seems to me that Ada offers only two ways to do this.
> 
> The first way is to make the constant a named number in A, or a constant 
> with a static value, and make a copy as a named number in B. Like this:
> 
>     package A is
>        I : constant Integer := 5;
>        -- A named number or (as here) a constant with a static value.
>     end A;
> 
>     with A;
>     package B is
>        My_I : constant := A.I;
>        -- A named number. This does not compile if A.I is non-constant,
>        -- or has a non-static value (even if constant).
>     end B;
> 
> However, this only works if the type of the constant is numeric.
> 
> The second way is just to document the reasons for the object being 
> declared constant, at the point of that declaration:
> 
>     package A is
>        I : constant Integer := 5;
>        -- This must be a constant, because package B etc. etc.
>     end A;
> 
> I see less reason for a run-time check of constancy. However, there is a 
> similar thing in Ada: the attribute 'Constrained. Perhaps there would be 
> some interest in an attribute 'Constant, which could be applied to any 
> object or named number and would be True for named numbers and constant 
> objects, and only for those. On first look, it seems very simple to 
> implement (but perhaps there is some complication in shared-code 
> generics...)
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Re: Test for constant (or "in parameter" in procedure)

[Jeffrey R. Carter]

On 02/09/2017 01:46 PM, reinkor wrote:
>
> i : Constant Integer := 5; -- all OK so far (but someone could
>                                change this to a variable)

If someone changes it to a variable, presumably it's because of a logic change 
in which it can no longer be constant. There would then be further changes to 
the code to make use of its new variability. In the process, the person making 
the change would come across your test and remove it, since it's no longer 
relevant. So I don't see that such a test would buy you anything.

If you have someone going around changing constants to variables for no reason, 
I suggest you no longer make use of that person's services.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Test for constant (or "in parameter" in procedure)

[Norman Worth]

reinkor wrote:
> Hi,
>
> is it a good way to test if an object is a constant or not (or "in parameter" in a procedure)? Something in addition to declare it as a constant?
>
> If I am sure an object is a constant (and can check it) then this can sometimes help to structure/optimize the code. I would like to have some redundancy and make sure an object is really constant when this is a prerequisite for a piece of code to be according to my intentions - i.e. if the object is messed with somewhere, then things could go wrong. So I would like some "local check" to be sure a constant is really a constant :-) Specially if many people are involved to change code over time.
>
> reinert
>
This might best be handled by a comment warning that the constant must 
be a constant (or in parameter) because of its later use.