[J3] [EXTERNAL] Private enumerators
Van.Snyder at jpl.nasa.gov
Fri Oct 25 16:11:55 EDT 2019
On Fri, 2019-10-25 at 14:25 -0400, Reuben D. Budiardja via J3 wrote:
> On 10/19/2019 01:37 PM, Van Snyder via J3 wrote:
> > Gary objected to private enumerators.
> > Access specs control access to identifiers, not objects.
> > He didn't like the possibility that one might be able to get the value
> > of an enumerator for which the module did not publish the name, using,
> > for example, INT(foo)+1 or foo%next().
> I share the concern regarding access to private enumerators. Being able
> to get the ordinal value of a private enumerator with NEXT() and turn it
> back using the constructor seems to defeat the point of the enumerator
> being private, and therefore a vulnerability.
If typed enumerators had been class (1) names, as BIND(C) enumerators
are, would you have objected to <access-spec> for them? Do you object
to <access-spec> for BIND(C) enumerators?
If you have a public generic interface (or binding) and some (or all) of
the specific procedures (or bindings) are private, the private ones can
still be invoked. Is that a problem?
> For example, suppose enumerators are being used to identify some state,
> then being able to iterate over the private enumerators with foo%next(),
> one can deduce how many (internal) states there are, and perhaps use
> this state as argument, etc, introducing vulnerability.
> I think it also defies "regular user's" expectation. I understand that
> we say ENUM is not derived type and enumerators are not component, but
> some similarities hold. With PRIVATE component, there is no access to
> the name or value of the component outside the module unless explicitly
If a private component appears after (or before) an array component, the
private component can be accessed by using out-of-bounds subscripts.
That's non-conforming. It wouldn't be difficult to make reference to
NEXT(X) non-conforming if NEXT(X) is a private enumerator, but what if
NEXT(NEXT(X)) isn't private?
> e.g. via getter and setter subroutines in the module. With ENUM
> as proposed, this is effectively provided and there is no way to disable it.
> I was thinking perhaps a solution is to require that all private
> enumerators to be defined after the public one, so that the ordinal
> values for private enumerators are always higher than the public one.
> Then, the requirements could be that NEXT() inside the module would
> traverse all the enumerators, while outside the module would only
> traverse the public enumerators. The same thing with LAST().
> Some examples:
> Example 1:
> enum, public :: color
> enumerator, public :: red, green
> enumerator, private :: purple ! <-- compile error,
> ! require all private after public
> enumerator, public :: blue
> end enum
> Example 2:
> module enum_def
> enum, public :: color
> enumerator :: red, green, blue
> enumerator, private :: purple, black
> end enum color
> type(color) :: my_car = color%blue
> my_car%last !-- would give "black"
> my_car = my_car%next() !-- would give purple
> end module enum_de
> module my_object
> use enum_def
> type(color) :: my_house = color%green
> my_house%last !-- would give "blue" since this is
> ! the last of the public enumerator
> my_house = my_house%next() !-- would give blue
> my_house = my_house%next() !-- ERROR terminated
> end module my_object
> End examples.
> I would be interested in feedback.
More information about the J3