Ignore:
Timestamp:
Nov 4, 2024, 12:21:11 PM (9 days ago)
Author:
Michael Brooks <mlbrooks@…>
Branches:
master
Children:
97ac01d3
Parents:
c3e41cda
Message:

Thesis, background, array: clarify C laxed inner dimension checking

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/mike_brooks_MMath/background.tex

    rc3e41cda r7d95bce9  
    685685Here, the distance between the first and second elements of each array depends on the inner dimension size.
    686686
    687 The last observation is a fact of the callee's perspective.
    688 There is little type-system checking, in the caller's perspective, that what is being passed, matches.
    689 \PAB{I do not understand}
    690 \begin{cfa}
    691 void f( float [][10] );
    692 int n = 100;
    693 float a[100], b[n];
    694 f(&a); // reject
    695 f(&b); // accept
    696 
     687This significance of an inner dimension's length is a fact of the callee's perspective.
     688In the caller's perspective, the type sytem is quite lax.
     689Here, there is (some, but) little checking that what is being passed, matches.
     690% void f( float [][10] );
     691% int n = 100;
     692% float a[100], b[n];
     693% f(&a); // reject
     694% f(&b); // accept
     695\begin{cfa}
    697696void foo() {
    698697        void f( float [][10] );
    699698        int n = 100;
    700699        float a[100], b[3][12], c[n], d[n][n];
    701         f( a );    // reject
    702         f( b );    // reject
    703         f( c );    // reject
    704         f( d );    // accept
    705         f( &a );   // reject
    706         f( &b );   // reject
    707         f( &c );   // accept
    708         f( &d );   // reject
     700        f( a );
     701        f( b );    $\C{// reject: inner dimension 12 for 10}$
     702        f( c );
     703        f( @d@ );  $\C{// accept with inner dimension n for 10}$
     704        f( &a );   $\C{// reject: inner dimension 100 for 10}$
     705        f( &b );
     706        f( @&c@ ); $\C{// accept with inner dimension n for 10}$
     707        f( &d );
    709708}
    710709\end{cfa}
    711 This size is therefore, a callee's assumption.
     710The cases without comments are rejections, but simply because the array ranks do not match; in the commented cases, the ranks match and the rules being discussed apply.
     711The cases @f(b)@ and @f(&a)@ show where some length checking occurs.
     712But this checking misses the cases @f(d)@ and @f(&c)@, allowing the calls with mismatched lengths, actually 100 for 10.
     713The C checking rule avoids false alarms, at the expense of safety, by allowing any combinations that involve dynamic values.
     714Ultimately, an inner dimension's size is a callee's \emph{assumption} because the type system uses declaration details in the callee's perspective that it does not enforce in the caller's perspective.
    712715
    713716Finally, to handle higher-dimensional VLAs, C repurposed the @*@ \emph{within} the dimension in a declaration to mean that the callee has make an assumption about the size, but no (unchecked, possibly wrong) information about this assumption is included for the caller-programmer's benefit/over-confidence.
Note: See TracChangeset for help on using the changeset viewer.