Subject: [Tsvwg] SCTP API - Clearing structures before use

From: Mark Butler <[email-masked]>
Date: Mon, 06 Mar 2006 15:01:06 -0700

I have another suggestion.  Somewhere the draft should specify that 
applications must clear all API structures before use.  That way when 
new fields are added and the applications are recompiled, the new fields 
are in a well known state.  This is a POSIX requirement for sockaddr_in6.

 - Mark.

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Tue, 07 Mar 2006 07:17:35 -0500

> are in a well known state.  This is a POSIX requirement for sockaddr_in6.
And what should be the handling by the kernel if
we do this.. should it return an error if all
the fields are not 0, or a valid value...

For example if I do a GET_PEER_ADDR_INFO and fill
in garbage in the RTO should you get an error back?

R

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Mark Butler <[email-masked]>
Date: Tue, 07 Mar 2006 13:30:37 -0700

Randall Stewart wrote:

>> new fields are added and the applications are recompiled, the new 
>> fields are in a well known state.  This is a POSIX requirement for 
>> sockaddr_in6.
>>
>> - Mark.
>>

Well that is ABI dependent to some degree, as in it depends on when 
certain fields were added to structures in a particular ABI.  If a field 
was added before support was present in the ABI, then that ABI does not 
have a problem.

To support extensibility for ABIs that previously supported a shorter 
version of a structure, new fields should preferably be defined such 
that zero leads to default behavior.

> in garbage in the RTO should you get an error back?

No.  The kernel is going to overwrite all OUT fields anyway  What 
matters is clearing IN and IN OUT fields.  Clearing the structure is 
good practice for getsockopt(2) calls if there are any IN fields or 
might be in the future. Structures should _always_ be cleared for 
setsockopt(2) calls.

Implementations should always clear the area between the end of the 
supported structure and the option length passed by the user in 
getsockopt(2) calls, so that applications can run on kernels that 
implement prior ABI versions, using the same zero is default behavior 
convention. 

New fields that are sensitive (i.e. zero means something unusual) may 
need structure / option length comparisons, either in the kernel or on 
the user side, as appropriate.  This does not work when applications are 
recompiled, unfortunately, and is a pain to implement anyway, compared 
to the simpler zero default convention.

 - Mark

---

From: Randall Stewart <[email-masked]>
Date: Thu, 09 Mar 2006 07:42:56 -0500

Mark:

This is all fine and good... apps should clear the structure
(except for the in params in certian cases).. however.. two questions.

1) Is it the place of the socket draft to specify that YE SHALL DO THIS
    to an application programmer... this is a meta question.. its fine
    if the answer is yes..

2) If the answer is yes, should there be some perscribed handling if the
    user does NOT do this. Qiaobing was always big on beating on me on
    SCTP that if you tell someone you must do X, then that also means
    you need to have an error path described... aka if the user does
    not do X then you will get this error... My initial inclination is
    I would hate to see you get an error just because you did not clear
    the fields... which then leads me to think, well if the kernel
    allows an uncleared set of fields in and acts the same, why insist
    the user do it... Maybe instead some overall goodness statement
    saying something like: "Whenever a get or set sockopt is called, it
    is always best if the caller clear's all non-input fields. This helps
    assure proper behavior when new fields are added"....

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Mark Butler <[email-masked]>
Date: Thu, 09 Mar 2006 08:33:59 -0700

>    to an application programmer... this is a meta question.. its fine

If the consequence of not doing something is potentially serious, then 
yes.  There shouldn't be any conflict between having an overall status 
of "Informational", and being able to define what it means to write a 
application or program that complies to the draft as specified.  If 
there is, there is a procedural problem somewhere that ought to be 
fixed.  It is worth noting that RFC2553 contains the word "must" (lower 
case) in several places, even though it is an informational RFC.

>    assure proper behavior when new fields are added"....

This is a condition that is impossible to check for in general, so you 
can't have a prescribed error. POSIX uses language like "If not X, the 
resulting behavior is undefined" (i.e. undesireable things might happen).

"Must" type language is preferable.  It puts users on notice that the 
interface is subject to future extensions.  It is worth noting that any 
decent compiler can optimize out or reduce redundant memset operations.  
The runtime overhead is usually zero.

 - Mark

---

From: Randall Stewart <[email-masked]>
Date: Fri, 10 Mar 2006 06:41:50 -0500

Mark:

It seems to me we could put some language in like that..

R