> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Derek M Jones > Sent: Friday, 01 August, 2008 10:33 > > ... redundancy is always > useful in that it provides an alternative view of the developers intent.
Agreed... > Inconsistency of intent is something that tools can zero in on. ... and agreed. However: > In both cases the developer may be unaware of changes to the > number of fields in the struct, or have incorrect beliefs > about the number of members. In many cases the developer shouldn't have *any* belief about the number of fields in the structure, as in the example in my previous note. In such cases, a coding practice that requires such a belief produces unnecessary and counterproductive coupling and breaks abstraction. An API can extend an opaque structure by appending new fields, without requiring source code changes in consuming code. Thanks to the "common prefix" rule, an API can even extend such a structure without requiring object changes, if the structure is defined with a modicum of forethought (so the implementation can tell whether the new fields are present, for example by using a version indicator in the prefix). My preference for abstract types in C is to use pointers to incomplete structures in the API, and only complete them in the implementation, with all operations on them implemented through API functions. But structures with documented and undocumented fields are a popular compromise, and in my opinion better than requiring consumers to write to a single, fixed representation and know it completely. In short, the developer's intent should often be: "I don't know, or care, how many fields this structure has. I'm going to initialize the whole thing, and then I'm going to set some fields explicitly, and I'm going to let the API implementation worry about the rest." Much (no doubt most) existing C code makes far too little use of abstraction. I can't endorse a blanket style rule that eliminates even more of it. -- Michael Wojcik Principal Software Systems Developer, Micro Focus _______________________________________________ splint-discuss mailing list splint-discuss@mail.cs.virginia.edu http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
