Subject: Inconsistency of types

From: Michael Tuexen <[email-masked]>
Date: Fri, 11 Mar 2005 01:02:35 +0100

Dear all,

the socket API ID currently defines the flags argument of the
sctp_sendmsg call as uint32_t and the flags field of the sctp_sndrcvinfo
structure to be an uint16_t. I think these should be the same and

I'm suggesting to change
    struct sctp_sndrcvinfo {
       uint16_t sinfo_stream;
       uint16_t sinfo_ssn;
       uint16_t sinfo_flags;
       uint32_t sinfo_ppid;
       uint32_t sinfo_context;
       uint32_t sinfo_timetolive;
       uint32_t sinfo_tsn;
       uint32_t sinfo_cumtsn;
       sctp_assoc_t sinfo_assoc_id;
    };
to
    struct sctp_sndrcvinfo {
       uint16_t sinfo_stream;
       uint16_t sinfo_ssn;
       uint32_t sinfo_flags;
       uint32_t sinfo_ppid;
       uint32_t sinfo_context;
       uint32_t sinfo_timetolive;
       uint32_t sinfo_tsn;
       uint32_t sinfo_cumtsn;
       sctp_assoc_t sinfo_assoc_id;
    };
What do you think?

Best regards
Michael

---

From: "Peter Lei (peterlei)" <[email-masked]>
Date: Thu, 10 Mar 2005 21:50:41 -0600

Yes, this makes more sense.  A nice side effect is that this
makes the 32-bit int's following it to be aligned correctly.

regards,
--peter

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 11 Mar 2005 12:09:08 -0800

>       sctp_assoc_t sinfo_assoc_id;

While this seems to be a simple change, it may cause binary
compatibility problems in some platforms.  And unlike a function
prototype change which can be worked around by bumping up
the library version number (assuming dynamic linked library)
such that binaries compiled with the old function call will
fail to work, the above simple change cannot be worked around
easily.  It can cause program to fail silently and it is
difficult to detect.  If we want it to be consistent with
sctp_sendmsg(), it is actually safer to change the sctp_sendmsg()
prototype as we can bump up the library version number,
assuming those sctp_* routines are implemented in a dynamic linked
library.

I understand that for most compilers in most platforms, the
above change normally should not cause a problem as the
sinfo_ppid will be 32 bit aligned irregardless of whether
sinfo_flags is 16 or 32 bit int.  I raise this issue as I
want to find out if people want the API draft to be as stable
as possible now as a lot of programs have been written using it.
And there may not be any easy work around for stack implementors
to support binary compatibility with some changes.  I expect
that new additions to the API are fine as long as they don't
break existing programs.

Comments and suggestions?

-- 

						K. Poon.
						[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 11 Mar 2005 22:43:10 +0100

Kacheong,

the important point for me is that the types are the same. So
it is OK to change the sctp_sendmsg call.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Mon, 14 Mar 2005 09:29:07 -0500

Hmm..

I wonder which would have less impact..

changing the function call from uint32 ->> uint16

OR

changing the structure???

Not sure..

The best choice IMO is what you did below.. but if
Kacheong prefers a function call change then I could
live with that too.. it still would cause a binary
incompatability though :-<

And as to the other changes MSG_ ---> SCTP_ this makes
sense... we should never have named them MSG_.. not sure
why we did :-D

R

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 14 Mar 2005 19:43:54 +0100

Dear all,

see my comments in-line.

Best regards
Michael

> changing the function call from uint32 ->> uint16
Since the function is implemented in a dynamic lib
it requires a change of the lib, which can be released
in a new version.
> changing the structure???
Since the structure is (I assume) also used in the kernel,
the new structure can not be introduced by updating the
kernel.
> Not sure..
If the above is correct, the change of the function call
seems simpler. Since this also requires a new version of
sctp.h the change (or addition) of the SCTP_ constants
should be no real problem. Or am I wrong, Kacheong?

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 14 Mar 2005 12:40:28 -0800

> should be no real problem. Or am I wrong, Kacheong?

This is the idea of a safer migration of the change.  Randy
is right that existing apps linked to the old lib will
fail to run if the old lib is not around, assuming that
only the latest lib will be shipped.  The point here is
that it is safer as the app breaks "spectacularly (-:"  So
users will notice immediately.  If only the structure is
changed, the breakage can be subtle and hard to detect.

I think that the structure change actually will not cause
any problem in most platforms.  But I still raise this issue
hoping to know what the users of the API draft think.  Do they
expect the API to be stable at this point?  Or can they still
accept incompatible changes?

-- 

						K. Poon.
						[email-masked]

---

From: David Lehmann <[email-masked]>
Date: Tue, 15 Mar 2005 08:19:34 -0500

> accept incompatible changes?

IMHO, the users should not expect the API to be stable until
the draft becomes an RFC.  Until then, it is just a draft, which
by definition, is subject to change.

-- 

David Lehmann
Ulticom, Inc.
http://www.ulticom.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Mar 2005 06:51:30 -0700

David,

And even then its INFORMATIONAL and can largely be ignored.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 15 Mar 2005 17:50:43 +0100

Brian,

see my comment in-line.

Best regards
Michael

> And even then its INFORMATIONAL and can largely be ignored.
I do not want to comment the status of an informational RFC,
but this ID, even as an ID, is NOT largely ignored. The *BSD and
Mac OS X (KAME), Linux (LKSCTP) and Solaris (part of Solaris 10)
Kernel implementations and the userland implementation from
www.sctp.de follow already this ID and it is also described
in the UNP book. People are using it and write cross plattform
applications.

So it is important
- that we make changes where necessary
- do not break implementations/applications where not necessary.

Best regards
Michael