Alex, 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. If both ways of doing the scruct are equally useful in picolisp (which I can see the use in case of willing to employ very tight data types or access some exotic hardware via some aliasing mechanism) then perhaps the two possibilities could be programmed, and the use be based in the "Principle of Least Surprise", which it seems to users of the intended (as docs stand now) be without "packing" of the structs. HTH -- Cesar Rabak On Tue, Dec 7, 2021 at 1:28 PM Alexander Burger <a...@software-lab.de> wrote: > Hi Jason, > > > But I have to respectfully disagree - 'struct' should know > > that if its current offset is 10, and it next needs to layout > > a 4-byte integer, it should insert 2 pad bytes to begin > > Equally respectful I have to re-disagree ;) > > 1. "'struct' should know" is not the case. It should just do what it is > told, > not trying to be clever. > > What if I *want* the above layout? 4 bytes at offset 10. I do not want > 'struct' to do something behind the scenes without need. > > 2. The reference for the 'native' and 'struct' initialization items says: > "a > pair (num . cnt) where 'num' is stored in a field of 'cnt' bytes". It > says > nothing about an integer. > > > Let me give an example of a use case. Let's say I want a fast way to store > 8 > bytes, with a single instruction, in memmory. Why should 'struct' stop me? > > (buf Ptr 10 > (struct Ptr NIL '(82 . 1) '(8243127052830861157 . 8) 0) > (println (struct Ptr '(B . 10))) > (println (struct Ptr 'S)) ) > (82 101 103 101 110 97 120 101 114 0 95 9 88 0 0 0) > "Regenaxer" > > I *want* to be able to store an 8-byte value at an offset of 1, if the > hardware > allows it. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
