Re: 'private' and Privacy

Re: 'private' and Privacy

[stefan-lucks]

On Tue, 7 Jul 2009, Rick wrote:

> I have:
> 
>    KEYPAD_ROWS_COUNT : constant Positive := 2;
>    -- The number of rows on a keypad.
> 
>    KEYPAD_COLUMNS_COUNT : constant Positive := 2;
>    -- The number of columns on a keypad.
> 
>    type Keys_Type is array
>      (1 .. KEYPAD_ROWS_COUNT, 1 .. KEYPAD_COLUMNS_COUNT)
>    of Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
>    --Intermediate, addressable storage of keys for the keypad.

How about this?

     -- solution 1

     type Keys_Type is array 
       (Integer range <>, Integer range <>) 
     of Item; 

     function Keys_Type_Create return Keys_Type is ...

This allows to actually create constrained Keys_Type arrays without making 
Keypad_Rows_Count and -_Columns_Count public. 

> I am trying to find a way to ensure that the user only addresses items
> in the array in the manner I provide rather than making use of the
> information clearly visible about the range of the array.  I can use
> functions instead of constants to define array range values but they
> have to be fully declared before I define the array - and this exposes
> that which I wish to remain private (the actual range).

Perhaps, what you want is the following: 

     -- solution 2

     type Keys_Type is limited private;

     function Get(KT: Keys_Type; X, Y: Integer) return Item;
     procedure Put(KT: Keys_Type; X, Y: Integer; It: Item); 

     ...

     private

       type Keys_Type is array(Secret_1 .. Secret_2, Secret_3 .. Secret_4) 
            of Item;

     end;

> Isn't this a contradiction in terms, or _is_ there a way to retain
> 'Privacy'?

Depends on what you mean by "privacy". For solution 1, your adversary/user 
would have to write

    X: Keys_Type := Keys_Type_Create;

and then could access X(I,J) -- but there are legal ways in Ada to figure 
out the ranges of X. 

Solution 2 requires to write the ranges into the private part of your 
spec. Private means, you can't use it, but the compiler must know -- and 
you can read it. (It always confused me, that the designers of Ada did put 
two different things into the same file: the specification for the user, 
i.e., the programmer going to "with" a package, and the private part, 
which actually is meant to be "compiler only".)

You can combine solution 1 and solution 2, to avoid explicitely writing 
your ranges in the spec. But whoever is able to read the implementation of 
Create_Key_Type still can figure out the ranges. 

Even if your user/adversary has no access to the source code of that 
implementation, what are you going to do if your user calls Put or Get 
with invalid indices? If you just raise an exception, the user could 
search for the ranges. If the lower bounds ("Secret_1" "Secret_3" above) 
are known (you seem to assume them to be 1), the user/adversary can find 
the secret constants KEYPAD_ROWS_COUNT and KEYPAD_COLUMNS_COUNT by running 
a binary search for each of the constants.

But what is the problem you really want to solve? 

If you need to protect confidential constants, Ada is unlikely to solve 
your problem.  But if you don't actually require confidentiality and just 
want to protect the user of your package from harming himself/herself, 
defining a private or limited private type and some put/get subprograms, 
as I did for solution 2, seems to be the way to go.


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

'private' and Privacy

[Rick]

I have never fathomed out why we declare entities in packages to be
'private' and then have to go and tell the world what is in them.  I
would assume that 'private' has something to do with 'information
hiding' yet we expose what is 'private'.

I have:

   KEYPAD_ROWS_COUNT : constant Positive := 2;
   -- The number of rows on a keypad.

   KEYPAD_COLUMNS_COUNT : constant Positive := 2;
   -- The number of columns on a keypad.

   type Keys_Type is array
     (1 .. KEYPAD_ROWS_COUNT, 1 .. KEYPAD_COLUMNS_COUNT)
   of Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
   --Intermediate, addressable storage of keys for the keypad.

I am trying to find a way to ensure that the user only addresses items
in the array in the manner I provide rather than making use of the
information clearly visible about the range of the array.  I can use
functions instead of constants to define array range values but they
have to be fully declared before I define the array - and this exposes
that which I wish to remain private (the actual range).

Isn't this a contradiction in terms, or _is_ there a way to retain
'Privacy'?
--------------------------------------------
Rick Duley
North Perth,
Western Australia
http://rickduley.webs.com
                                      .-_|\
                                     /     \
                               perth *_.-._/
                                          v
aussie : 0409 106 049
o'seas : +61 409 106 049
--------------------------------------------
"Answers are easy;
         it's asking the right questions
                             which is hard."
The Doctor (Dr Who: The Face of Evil (1977)"

Re: 'private' and Privacy

[Gautier write-only]

On 8 Jul., 04:48, Rick <rickdu...@gmail.com> wrote:
> I have never fathomed out why we declare entities in packages to be
> 'private' and then have to go and tell the world what is in them.

I also wondered why, until I began using it. I elaborate on your
example:

package Test_private_pkg is

   type Key_Type is private;
   type Keys_Type is private;

   procedure Define_Key(k: Key_Type; val: Integer);
   --
   function Get_Key(k: Keys_Type; i,j: Integer) return Key_Type;
   procedure Set_Key(k: Keys_Type; i,j: Integer; new_val: Key_Type);

private

   type Key_Type is new Integer;

   KEYPAD_ROWS_COUNT : constant Positive := 2;
   -- The number of rows on a keypad.
   KEYPAD_COLUMNS_COUNT : constant Positive := 2;
   -- The number of columns on a keypad.
   type Keys_Type is array
     (1 .. KEYPAD_ROWS_COUNT, 1 .. KEYPAD_COLUMNS_COUNT)
   of Key_Type;

end;

> I am trying to find a way to ensure that the user only addresses items
> in the array in the manner I provide rather than making use of the
> information clearly visible about the range of the array.

Now, with the private definitions as above, we have exactly what you
need:

with Test_private_pkg;
use Test_private_pkg;

procedure Test_private is

  key: Key_Type;
  keys: Keys_Type;

  i: Integer;

begin
  Define_key(key, 123);
  Set_Key(keys, 1,2, key);

  i:= KEYPAD_ROWS_COUNT; -- You don't want the user to do that

>>> test_private.adb:15:07: "KEYPAD_ROWS_COUNT" is not visible
>>> test_private.adb:15:07: non-visible (private) declaration at test_private_pkg.ads:15

The reason why the private things are not hidden is that the compiler
needs to know about type sizes and perhaps other details when using
the private types.
If you have to really hide information (passwords, software
registration ID's,... ), you need to use functions, provide the
specification and not the body's source code, and in the body you may
even need to encrypt your stuff. But it is another topic...
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/

NB: For a direct answer, e-mail address on the Web site!

Re: 'private' and Privacy

[Ludovic Brenta]

Rick Duley wrote on comp.lang.ada:
> I have never fathomed out why we declare entities in packages to be
> 'private' and then have to go and tell the world what is in them.  I
> would assume that 'private' has something to do with 'information
> hiding' yet we expose what is 'private'.

Because the compiler needs to know the sizes of all types and objects
so it can emit the code for passing parameters to the subprograms
declared in the package.  Ada is designed in such a way that all the
information is in the spec, so the compiler needs not look at the
body.  This in turn makes it possible to provide only the specs and
not the source files for the body.

> I have:
>
>    KEYPAD_ROWS_COUNT : constant Positive := 2;
>    -- The number of rows on a keypad.
>
>    KEYPAD_COLUMNS_COUNT : constant Positive := 2;
>    -- The number of columns on a keypad.
>
>    type Keys_Type is array
>      (1 .. KEYPAD_ROWS_COUNT, 1 .. KEYPAD_COLUMNS_COUNT)
>    of Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
>    --Intermediate, addressable storage of keys for the keypad.
>
> I am trying to find a way to ensure that the user only addresses items
> in the array in the manner I provide rather than making use of the
> information clearly visible about the range of the array.  I can use
> functions instead of constants to define array range values but they
> have to be fully declared before I define the array - and this exposes
> that which I wish to remain private (the actual range).
>
> Isn't this a contradiction in terms, or _is_ there a way to retain
> 'Privacy'?

It seems to me that you have a design problem.

On the one hand, you expose to the client the fact that you model your
widget with an array of buttons; on the other hand you don't want your
client to know the bounds of the array.  I think there is a
contradiction inherent in this design.

You can resolve the contradiction in two ways:

1) expose the array type and allow the client to index into the array
directly. Prevent out-of-bounds indexes with strong typing:

package Keypad is
   ROWS_COUNT : constant := 2;
   COLUMNS_COUNT : constant := 2;

   type Row_Index is range 1 .. ROWS_COUNT;
   type Column_Index is range 1 .. COLUMNS_COUNT;
   type Keys_Type is array (Row_Index, Column_Index) of
     Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
end Keypad;

2) provide only an abstract data type where the only operations are in
terms of the semantics of each button; hide the fact that there is an
array behind the scenes.  If there is only one keypad, this is a
singleton, so you don't even need any type declaration in the spec:

with Gtk.Key_Button_Pkg;
package Keypad is
   function First_Button return
Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
   function Second_Button return
Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
   function Third_Button return
Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
   function Fourth_Button return
Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
end Keypad;

package body Keypad is
   ROWS_COUNT : constant := 2;
   COLUMNS_COUNT : constant := 2;

   type Row_Index is range 1 .. ROWS_COUNT;
   type Column_Index is range 1 .. COLUMNS_COUNT;
   Button : array (Row_Index, Column_Index) of
     Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;

   function First_Button return
Gtk.Key_Button_Pkg.Gtk_Key_Button_Access is
   begin
      return Button (1, 1);
   end First_Button;
   -- etc.
end Keypad;

(if there are several keypads, you declare an abstract data type as
usual:

type Keypad_Type (<>) is limited private;
function Construct return Keypad_Type;
function First_Button (KP : Keypad_Type)
  return Gtk.Key_Button_Pkg.Gtk_Key_Button_Access;
-- etc.
)

HTH

--
Ludovic Brenta.

Re: 'private' and Privacy

[(see below)]

On 08/07/2009 03:48, in article
843a36b0-041d-4826-98b4-0fbcb1a4d287@d9g2000prh.googlegroups.com, "Rick"
<rickduley@gmail.com> wrote:

> I have never fathomed out why we declare entities in packages to be
> 'private' and then have to go and tell the world what is in them.  I
> would assume that 'private' has something to do with 'information
> hiding' yet we expose what is 'private'.

In this context 'private' is a technical property. It means that the
following details are hidden from client code, not from a human reader.

It is not clear how the latter restriction might be imposed.
White-on-white pixels? Invisible printer ink? 8-)

(Yes, I know about LIS and its triple package components.)

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk