[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Indexing array values with offsets, and constructing arrays by

From: Indu Bhagat
Subject: Re: [RFC] Indexing array values with offsets, and constructing arrays by size
Date: Wed, 17 Feb 2021 22:44:10 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

On 2/17/21 3:47 PM, Jose E. Marchesi wrote:

Hi Indu.

On 2/17/21 10:12 AM, Jose E. Marchesi wrote:
In the recent work with btf.pk that David Faust did, we have
like this:
type BTF_Section =
      string[header.str_len] strings @ str_off;
      /* Given an offset into the BTF strings section, return the
string.  */
      method get_string = (offset<uint<32>,B> off) string:
          return string @ strings'offset + off;
i.e. the string table in the BTF section can be comfortably
expressed as
an array of strings.
But then, in the BTF world strings are referred using an offset
to the string table, and not the ordinal order of the string in the
table.  This is similar to other string tables in other formats like
The method above works, but it has a problem: it is not what I call
"agnostic" Poke code.  This means that the code needs assumes the data
is mapped.  In this case, the method only works when invoked in a BTF
section that is mapped.
Most Poke code should be agnostic if needed, so I am proposing two
additions to the language:
1) Indexing array values with offsets.
     We shall support indexing arrays, both mapped and non-mapped,
with an
     offset value.  Like in:
     var a = [1,2,3];
     a[0#B] -> 1
     a[4#B] -> 2
     a[8#B] -> 3
     The provided offset should match the offset of some particular
     element in the array.  Otherwise, we get an E_out_of_bounds
     a[5#B] -> raises E_out_of_bounds
     a[10#Kb] -> raises E_out_of_bounds
     Using this support, we don't need the `get_string' method above.
     Given an offset into the string table the user can just do:
     which would be agnostic Poke code: it would work as well with
     mapped and non-mapped BTF sections.

It makes sense to consolidate the semantics for array access using
offset for both mapped and non-mapped arrays.

Regarding the error: as a user, a first reaction when I see a
E_out_of_bounds for a[5#B] is confusing because the access is within
bounds, it just happens to be an invalid one.

How about :
    a[5#B] -> raises E_invalid_access
    a[10#Kb] -> raises E_out_of_bounds

Ok, you are definitely right in that out_of_bounds is confusing for the
first case.

Then again, why having two exceptions?  We can just use an
E_invalid_index for every invalid indexation, regardless of the nature
of the index.

Now E_invalid_index for a[10#Kb] is misleading to a similar degree :|
If I have to pick just one exception that fits both proposals, I guess E_out_of_bounds is it.

     The question with this is: what exception to raise when the given
     size doesn't span for a whole number of the elements of the array
     type?  Currently, that situation when mapping arrays by size raises
     E_map_bounds.  I think in the case of constructing by size we should
     raise E_out_of_bounds instead.

IMO, on first look, E_out_of_bounds looks acceptable here.

I have a question though (applicable to both these proposals) - Will
the user get E_map_bounds/E_out_of_bounds depending on whether the
element is mapped or not ?

Hmmm, yes, and that is not agnostic :/


What about just renaming E_map_bounds to E_out_of_bounds?

For this case, yes renaming E_map_bounds to E_out_of_bounds is reasonable.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]