Changes between Version 22 and Version 23 of ForeignFunctionInterface


Ignore:
Timestamp:
Oct 21, 2009 11:49:09 AM (4 years ago)
Author:
chak@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ForeignFunctionInterface

    v22 v23  
    1818 * Inappropriate use can subvert all semantic guarantees provided by Haskell and can cause memory corruption and program crashes. 
    1919 
    20  
    21 ---- 
    22  
    23 == Open Questions == 
    24  
    25 The following topics still require a bit of discussion or a decision between multiple alternatives. 
    26  
    27 === Reinitialisation after `hs_exit()` === 
    28  
    29 The FFI addendum currently requires that `hs_exit()` can be followed by another `hs_init()`.  GHC doesn't support that and I am not convinced that we should require it.  I propose to remove that requirement. 
    30  
    31 '''TODO:''' Decide whether we remove the requirement for re-initialisation. 
    32  
    33 === Alignment === 
    34  
    35 Except for `mallocBytes` & `allocaBytes`, the original FFI addendum does not specify any constraints on alignment for allocated memory (by `mallocForeignPtrBytes` and others).  This is clearly an oversight.  The questions is how we want to express the fact that all routines that allocate memory specified in bytes must conform to a set of alignment constraints (this was proposed by Thomas !DuBuisson and John Meacham)  We may add the following statement concerning alignment at the beginning of Section 5 (which describes the library modules): 
    36  
    37   All storage allocated by functions that allocate based on a '''size in bytes''' must be sufficiently aligned for any of the basic foreign types (see Section 3.2) that fits into the newly allocated storage. All storage allocated by functions that allocated based on a '''specific type''' must be sufficiently aligned for that type.  Array allocation routines need to obey the same alignment constraints for each array element. 
    38  
    39 '''TODO:''' Decide whether we want to add this text.  If not, we need to find an alternative way of expressing the required alignment constraints. 
    4020 
    4121---- 
     
    7656 * We omit the functions that, in the standard libraries, have been moved from `Foreign.Marshal.Error` to `System.IO.Error` (namely those to construct I/O errors). 
    7757 
     58=== Alignment === 
     59 
     60Except for `mallocBytes` & `allocaBytes`, the original FFI addendum does not specify any constraints on alignment for allocated memory (by `mallocForeignPtrBytes` and others).  This is clearly an oversight.  We add the following statement concerning alignment at the beginning of Section 5 (which describes the library modules): 
     61 
     62  All storage allocated by functions that allocate based on a '''size in bytes''' must be sufficiently aligned for any of the basic foreign types (see Section 3.2) that fits into the newly allocated storage. All storage allocated by functions that allocated based on a '''specific type''' must be sufficiently aligned for that type.  Array allocation routines need to obey the same alignment constraints for each array element. 
     63 
    7864=== Transparent marshalling of newtypes === 
    7965 
     
    8975 
    9076Multi-threading support is implementation-specific. 
     77 
     78 
     79---- 
     80 
     81== Considerations for the future ==