Hi everyone, Great discussion, thank you all!
> 'native' and 'struct' do exactly what the programmer tells them. Nothing > tricky > or clever behind the scenes. I do not want them to insert bytes based on > assumptions. Sounds right to me, no hidden magic please. But yes to more comfort. Maybe a higher level function "structC" to take care of ISO standard C default conventions is warranted? Similiar like we have multiple related functions to handle multipe date conventions, e.g. 'dat$' and 'datStr'. This new function in turn might make use of the more basic "struct" function. Just a question/idea, maybe nonsense: Is (struct) really limited to use with (native)? Could it not also be handy to use (struct) when processing binary network protocols, unrelated to C FFI? > You can disagree, but cannot keep disagreeing and maintain the > documentation related to the implementation "Creates or extracts data > structures, suitable to be passed to or returned from native C functions." > If the idea is as you describe, then the doc should be reformed and > the user instructed to check the needs according to the call he/she > intends, on the other hand. I suspect you're interpreting this sentence quite differently, with Alex understanding/intending it as a much more general statement (helper to build memory blocks to use with C FFI) than how Cesar and Andras read it (helper to construct structs which meet the "usual" expectations of a C interface). I agree this statement needs a more accurate wording if it leads readers astray. @Cesar: If you like to customize (struct) to your needs, have a look at (redefine). If you want to do a redefine only locally, you could write a custom FEXPR making use of (patch). -beneroth -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
