From baker@ada.cs.fsu.edu Wed Apr 12 09:03:55 1995 Received: from knosof.demon.co.uk by dkuug.dk with SMTP id AA12299 (5.65c8/IDA-1.4.4j for ); Thu, 13 Apr 1995 01:50:49 +0200 Received: from punt2.demon.co.uk by knosof.demon.co.uk with SMTP id AA819 ; Thu, 13 Apr 95 00:49:39 BST Received: from punt2.demon.co.uk via puntmail for wg15@knosof.demon.co.uk; Wed, 12 Apr 95 17:07:30 GMT Received: from ada.cs.fsu.edu by punt2.demon.co.uk id aa28073; 12 Apr 95 18:06 GMT-60:00 Received: by ada.cs.fsu.edu (5.65/56) id AA12397; Wed, 12 Apr 95 13:03:55 -0400 Date: Wed, 12 Apr 95 13:03:55 -0400 From: Ted Baker Message-Id: <9504121703.AA12397@ada.cs.fsu.edu> To: derek@knosof.demon.co.uk, wg15@knosof.demon.co.uk Subject: Re: (wg15tag 924) (SC22WG15.493) Re: (wg15-uk 699) Feedback to WG15 on WG15 N511 from the U.S. WG15 TAG X-Charset: ASCII X-Char-Esc: 29 The idea of testing applications for conformance to the POSIX standards makes sense to me, BUT, it seems such tests could go further than I have seen suggested in e-mail so far. A reasonable test facility for application conformance to POSIX.1 would be a bare-bones implementation, that minimally satisfies the standard. A conformant application must be able to be compiled and run on such a least-common-denominator implementation. A minimal POSIX implementation used for this purpose must not support any of the optional functionality, and must not provide any implementation-defined extensions. All configurable system limits must be the minimum portable values. (For example, _POSIX_OPEN_MAX=16.) The system should trap and reject calls from signal handlers to all POSIX operations that are not specified as async-signal safe. In some cases, the system might need to be configurable so as to provide a range of behaviors, where POSIX allows this, such as filename truncation: the application would need to work correctly both with and without filename truncation, so the program would need to be tested with two different configurations of the test-system. Of course, as with any form of testing, this would not be 100% effective. --Ted Baker PS: To be fair, I acknowledge that POSIX permits a very wide range of behaviors, so that there is probably no unique "minimal" implementation, unless (and I'm not sure I'm reading this correctly) a null implementation would be considered conformant. In section 2.4, it says "Implementations may support errors not included in this clause." Does this mean an implementation could define an error "E_BADLUCK" and return this randomly for every POSIX call? Even without this, there are some difficult-to-test freedoms given to the implementation. For example, the Dave Emery raised the following examples in e-mail circulated in WG9: | In fact, there's a general issue of 'interfaces' that the | VRG should look at. How well defined should a specification | be before it can be considered "safe"? There are some significant | unspecified behaviors in POSIX (ISO 9945-1); some of these are | things that can happen quite easily if you aren't 100% conversant | on the specification. | For instance, some of the C interfaces look like the following: | char * get_whatever (param); | char * param; | So, one might ask, what happens if param is null? Good Question! | The specification is (deliberately) silent on this situation. | Current practice is split, some systems allocate new storage | and return the pointer to the newly-allocated storage, while | other systems report this as an error. The reason for deliberate | silence (according to one insider I asked) was to achieve consensus, | they allowed both behaviors, and "Of course anything not specified | in the standard is implementation-defined.") | Another question on the same style of interface: | Given "set_whatever (param); char * param;" | Is the following a "acceptable" usage? | char *x; | x = malloc (20): /* allocate 20 bytes for a string */ | x = get_20_character_string(); /* not important */ | set_whatever (x); /* pass to POSIX */ | free (x); /* now clean up storage */ | This looks quite fit and proper, but IT MIGHT NOT BE! It's | quite "legal" for the system to keep the pointer passed to it, | and not copy the contents of the pointer. Thus, freeing (or | overwriting) the pointer will inadvertently change the setting | passed to POSIX. POSIX tends to handle this situation a bit | better, but X Windows, for instance, is notorious for not | documenting this kind of thing.