ross@spam.ua.oz.au (Ross Williams) (06/21/91)
Ian Taylor (ian@airs.com) writes of the proposed data compression standard: CRIT_003: USE OF MEMORY ----------------------- >>2.3 Use of Memory >>----------------- >>2.3.1 A conforming procedure must read and write only the memory in >>the parameters of its parameter list with the exception of some >>"extra" memory (which can take the form of registers or local stack >>variables) which it may use for temporary use, subject to the >>following conditions: > >> 1) The particular language/environment must ensure that the memory >> will be available (i.e. failure during allocation is impossible). >> 2) The total size of the extra memory does not exceed 1024 bytes. >> 3) The memory is not used to transfer information in or out of the >> instantiation of the conforming procedure. > >This doesn't quite make sense to me as written, although this is >really just nitpicking. The program itself is probably in memory, and >it surely acceptable to read it. It is surely also acceptable to use >some sort of constant table during compression (a precomputed >frequency count, perhaps). Finally, restriction 3 appears to prohibit >the accumulation of statistics across several calls; if those >statistics do not affect the compression, but merely provide >information that the program can access in some non-standard fashion, >why prohibit them? This aim of this section of the standard was to allow the creation and use of data within the lifespan of the procedure invocation while still making it absolutely clear that the procedure should only communicate with the outside world through its parameter list. It is very dangerous for a compression procedure to read non-parameter memory as the compression procedure should not "know" anything about its environment except that which it received through its parameter list. This is in the name of portability. Use of a constant table is acceptable and encouraged so long as the table is a static read-only component of the code. In effect, it then IS part of the code. I sympathize with the backdoor statistics idea. I have used this technique often myself. However, one of the goals (if not THE goal) of this standard is to define constraints that allow data compression procedures to be quickly and simply interchanged. If a procedure is writing data out the back door then it hardly qualifies as standard, as the mechanisms by which it connects to the backdoor reader or memory will render it non-portable. There is nothing to stop those who wish to write such non-standard procedures and run them under a standard test harness. However, I do not think that they can reasonably call the procedure with the backdoor code in it "standard". I think that your comments show that the wording of this part of the standard should be tightened. I will make a note of it. >>2.6.3 The identity record must contain the information contained in >>the fields of the following "model" record: > >How about a field for the version number of the standard, so that new >fields can be more easily added to this record? A good suggestion which I think should be acted upon. I will make a note of it. Thank you for your comments, Ross Williams ross@spam.ua.oz.au