[osiris-devel] Osiris 2.4.4-stable released

[Alexei Roudnev]

Yes, but adjustmenmt depends of the memory model, so it shoul not  be used
in protocol, when possible.

I agree (may be) that it is reasonable to keep **64 adjustments instead of
**32 ones. Anyway, 2.4.4 works on all Solaris systems without any problems;
I believe, that failure was caused by using /64 bit mode instead of /32 bit
mode (no any good reason to use 64 bits in Osiris).

Sparc GCC:
     -m32
-m64
Generate code for a 32-bit or 64-bit environment. The 32-bit environment
sets int, long and pointer to 32 bits. The 64-bit environment sets int to 32
bits and long and pointer to 64 bits.


Of course, it may be too late change osiris-3 back.

PS, Strange example - it is 100% machine dependent... This program violate
all possible rules.Additionally, internal data structures should not be used
in network without packing/unpacking or binary<->text conversion. Windows
have pragma to control data adjustment; moreover, it is critical to
translate SSL in the same mode, as your program (we had some fun with this
problem 1 year ago).

----- Original Message ----- 
From: "Brian Wotring" <brian at shmoo.com>
To: "Osiris Developers" <osiris-devel at lists.shmoo.com>
Sent: Thursday, January 29, 2004 7:37 AM
Subject: Re: [osiris-devel] Osiris 2.4.4-stable released


>
> Here is an example of code that will seg, it demonstrates the problem,
> exactly.  Correctly define the foo structure with an additional short,
> and everything is happy.
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> struct foo
> {
>      short x;
>      short y;
>      short z;
> };
>
> struct bar
> {
>      long long gold;
>      char buf[1024];
> };
>
> int main()
> {
>      struct foo myfoo;
>      struct bar mybar;
>
>      struct bar * realbar;
>
>      char *buf = (char *)malloc( sizeof( myfoo ) + sizeof( mybar ) );
>      mybar.gold = 4;
>
>      memcpy( buf, &myfoo, sizeof( myfoo ) );
>      memcpy( (buf+sizeof(myfoo)), &mybar, sizeof( mybar ) );
>
>      realbar = (struct bar *)( buf + sizeof( myfoo ) );
>      fprintf( stderr, "gold is: %llu\n", realbar->gold );
>
>      return 0;
> }
>
>
> On Jan 28, 2004, at 11:42 AM, Alexei_Roudnev wrote:
>
> > It is not hardware issue; it is (more likely) compilation mode issue.
> > For
> > Solaris, I strongly recommend to have binary version, built on Solaris
> > 2.7 /
> > Ultra Sparc / 32 bits, which can work on ANY hardware and ANY software
> > (Solaris 2./7 - 2.9), and forget about this problem. You can not align
> > network data structure to theparticular hardware (what if next Sun
> > will have
> > 126bit mode - change structures again?).
> >
> > Moreover, I am 100% sure that C compiler allows to use un-aligned
> > structures
> > in 64 bit mode, just look for the compiler options.
> >
> > ----- Original Message -----
> > From: "Brian Wotring" <brian at shmoo.com>
> > To: "Osiris Developers" <osiris-devel at lists.shmoo.com>
> > Sent: Wednesday, January 28, 2004 5:07 AM
> > Subject: Re: [osiris-devel] Osiris 2.4.4-stable released
> >
> >
> >>
> >> You are correct, it would effect OpenBSD running on this hardware.
> >>
> >> On Jan 27, 2004, at 6:02 PM, Richard Johnson wrote:
> >>
> >>> At 06:23 -0700 on 2004-01-26, Brian Wotring wrote:
> >>>> - - this release changes the message header structure used
> >>>>    throughout the components of the Osiris sytem.  Thus,
> >>>>    this release is not compatible with previous releases.
> >>>>    The changes was necessary in order to fix an alignment
> >>>>    problem on Solaris.
> >>>
> >>>
> >>> While I understand this fix isn't actually in until the rel_3_dev
> >>> branch,
> >>> the alignment problem doesn't seem to affect just Solaris:
> >>>
> >>>  | $ uname -mpsv
> >>>  | OpenBSD GENERIC#4 sparc64 SUNW,UltraSPARC-IIi @ 333 MHz, version 0
> >>> FPU
> >>>  | $ dmesg | grep '3.4-current'
> >>>  | OpenBSD 3.4-current (GENERIC) #4: Fri Jan 23 17:29:32 MST 2004
> >>>  | $ osiris
> >>>  | Osiris command line management utility - version 2.4.4-stable
> >>>  | authenticating to (localhost)
> >>>  |
> >>>  | User: admin
> >>>  | Password:
> >>>  |
> >>>  | [frozen here]
> >>>
> >>> The freeze noted in 2.4.4 does not occur in 3.0.1-current, so I
> >>> suspect the
> >>> alignment fix was the key for OpenBSD sparc64 support as well.
> >>>
> >>>
> >>> Richard
> >>> _______________________________________________
> >>> osiris-devel mailing list
> >>> osiris-devel at lists.shmoo.com
> >>> https://lists.shmoo.com/mailman/listinfo/osiris-devel
> >>>
> >>>
> >> --
> >>      Brian Wotring ( brian at shmoo.com )
> >>      PGP KeyID: 0x9674763D
> >>
> >> _______________________________________________
> >> osiris-devel mailing list
> >> osiris-devel at lists.shmoo.com
> >> https://lists.shmoo.com/mailman/listinfo/osiris-devel
> >>
> >
> > _______________________________________________
> > osiris-devel mailing list
> > osiris-devel at lists.shmoo.com
> > https://lists.shmoo.com/mailman/listinfo/osiris-devel
> >
> >
> --
>      Brian Wotring ( brian at shmoo.com )
>      PGP KeyID: 0x9674763D
>
> _______________________________________________
> osiris-devel mailing list
> osiris-devel at lists.shmoo.com
> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>