Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!decwrl!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: How to represent structs in text
Message-ID: <60788@sun.uucp>
Date: 21 Jul 88 06:58:19 GMT
References: <759@vsi.UUCP> <7351@cit-vax.Caltech.Edu>
Sender: news@sun.uucp
Lines: 28

> 	Showing just the members seems to indicate to me that the members
> listed are definitely there, but other members might be as well which
> should really not be tampered with. This is simply information-hiding
> which might be better done implemented in software than by lack of reference
> in the documentation.

No, it's not just information-hiding.  It's also indicating that there may be
other members in future implementations, for example.  The SVID, and the System
III/System V "stat" documentation, for example, do not show the "stat"
structure, they just list some of the members; thus, a system that provides the
4.2BSD "stat" structure is not incompliant with the SVID nor incompatible with
System V merely by virtue of having the 4.2BSD "stat" structure.  (No
complaints about "utime" being passed a pointer to "st_atime" and not working,
please; the SVID and the S3/S5 documentation and "lint" library go out of their
way to discourage this practice.)

> 	For system programmers and other down&dirty implementors, entire
> structures should be the norm; end users deserve the watered-down partial
> structure revelation normally; programmers need one or the other depending
> on what level of detail they need.

As a system programmer, I prefer getting the entire structure *only* when it's
written to files or network connections, for example (and, in this modern
world, dumping structures directly to files or network connections -
*especially* to network connections - is often a Bad Thing; take 4BSD "talk" -
please!).  For most of the structures I have to deal with at that level of
detail, the documentation of the exact layout is online in the include files,
which tends to suffice.