[M3devel] packing problem… how exactly does modula-3 pack data into records?? … "solved"

[Daniel Alejandro Benavides D.]

Hi all:
in fact I think the main issue is the Assumption that everywhere there is C, which is just as wrong, as their claim "C is portable", what we need is but with other Wirth languages, more than the Outside world claims C is the best language ever I'm convinced this is to say "whether C is not better than others we don't care as we don't know neither". Is just outside ignorance.
If hackers were rather worried about their safety they wouldn't be using C as an application programming language is clear.
That said, look what is done in Linux since there isn't much security in its driver base, which is the "most precious treasure of Gnu/Linux hackers"
they just don't know when a driver will just bring the system absolutely down. (And yet they criticize Modula-3 RT exception of bringing down the system, yet SPIN changed that)
That said, Gnu/Linux has been proposed a real API of safe drivers, but basically it means all drivers should be written in a type safe language.
My problem is not against C, as many others I don't hate it, I really like it, but for real systems programming I do much prefer Modula-3. C isn't the issue here, if you can prove the system is well typed, there isn't much to discuss, but if not, what are we doing with that (we don't what this programs can do BTW).
I do prefer Gnu/Linux platform of development but "I can't trusty this machines" some dear Friend of this community said.
Thanks in advance

--- El vie, 20/1/12, Jay <jay.krell at cornell.edu> escribió:

> De: Jay <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] packing problem… how exactly does modula-3 pack data into records?? … "solved"
> Para: "Dragiša Durić" <dragisha at m3w.org>
> CC: "m3devel" <m3devel at elegosoft.com>, "Jay K" <jay.krell at cornell.edu>
> Fecha: viernes, 20 de enero, 2012 13:11
> As in C, if you need portability and
> predictability, just don't use bitfields. Use integer types
> of size 8, 16, 32, or possibly 64 bits, and do the
> appropriate shifting and masking, possibly
> endian-dependent.
> 
> 
> Actually, to avoid endian and packing/alignment concerns,
> use only 8 bit integers and optionally pack/unpack into more
> convenient types.
> 
> 
>  - Jay (phone)
> 
> On Jan 20, 2012, at 4:02 AM, Dragiša Durić <dragisha at m3w.org>
> wrote:
> 
> > TYPE
> >  (* This is how it should be written... If only
> cm3 packed left-to-right-until-spent. todo for me.
> > 
> >  TSPacketHeader = RECORD
> >    sync: BITS 8 FOR
> [16_0..16_ff];   (* Always 0x47 *)
> >    tErrInd,       
>               (*
> Transport Error Indicator *)
> >    pusi: BITS 1 FOR BOOLEAN; 
>    (* Payload Unit Start Indicator *)
> >    transPrio: BITS 1 FOR [0..1];
> >    pid: BITS 13 FOR PID;
> >    transScramControl: BITS 2 FOR [0..3]; (*
> 00 means no scrambling *)
> >    afc: BITS 2 FOR [0..3]; (* 01 - no
> adaptation field, payload only *)
> >    cc: BITS 4 FOR Nibble;
> >  END;
> >  *)
> > 
> >  TSPacketHeader = RECORD
> >    sync: BITS 8 FOR
> [16_0..16_ff];   (* Always 0x47 *)
> > 
> >    pidHi: BITS 5 FOR [16_00..16_1f];
> >    transPrio: BITS 1 FOR [0..1];
> >    pusi,
> >    tErrInd: BITS 1 FOR BOOLEAN;
> > 
> >    pidLo: BITS 8 FOR [16_00..16_ff];
> > 
> >    cc: BITS 4 FOR Nibble;
> >    afc: BITS 2 FOR [0..3]; (* 01 - no
> adaptation field, payload only *)
> >    transScramControl: BITS 2 FOR [0..3]; (*
> 00 means no scrambling *)
> >  END;
> > 
> > With additional methods for getPid() and setPid(),
> this works as expected.
> > 
> > But I _really_ think we should have continuous bit
> fields in cases where it spans byte boundary and combined
> with how other pieces of this work now - it means we need
> left to right packing of bit strings into bytes, not right
> to left as it is done now on my x86_64 box. This is probably
> some endianess relict, but I also think endiannes has
> nothing to do with us once we decide to go bit strings.
> > 
> > I don't see a big problem to implement this in such a
> way right now. Especially since at this moment nobody is
> having any expectations from implementation (except me O:) )
> - we won't break anything.
> > 
> > TIA,
> > dd
> > 
> > On Jan 20, 2012, at 8:29 AM, Dragiša Durić wrote:
> > 
> >> I am not using packing to interface with C or to
> be compact.
> >> 
> >> My code is directly producing packets for some
> network protocol. No C in sight :). 
> >> 
> >> And, as probably all those pesky :) network
> protocols around… Order of bytes and (expected) order of
> bits is - left to right.
> >> 
> >> I really do not understand why this is something
> hard to accept as standard (or at least cm3) way for 
> bit packing?
> > 
>