.. mode: -*- rst -*- The WriteF function =================== :Tag: design.mps.writef :Author: Richard Brooksby :Date: 1996-10-18 :Status: complete design :Revision: $Id: //info.ravenbrook.com/project/mps/master/design/writef.txt#17 $ :Copyright: See `Copyright and License`_. :Index terms: pair: WriteF function; design Introduction ------------ _`.intro`: This document describes the ``WriteF()`` function, which allows formatted output in a manner similar to ``printf()`` from the Standard C library, but allows the Memory Pool Manager (MPM) to operate in a freestanding environment (see design.mps.exec-env_). .. _design.mps.exec-env: exec-env _`.background`: The documents design.mps.exec-env_ and design.mps.lib_ describe the design of the library interface and the reason that it exists. .. _design.mps.lib: lib Design ------ _`.no-printf`: There is no dependency on ``printf()``. The MPM only depends on ``mps_io_fputc()`` and ``mps_io_fputs()``, via the library interface (design.mps.lib_), part of the *plinth*. This makes it much easier to deploy the MPS in a freestanding environment. This is achieved by implementing our own output routines. _`.writef`: Our output requirements are few, so the code is short. The only output function which should be used in the rest of the MPM is ``WriteF()``. ``Res WriteF(mps_lib_FILE *stream, Count depth, ...)`` If ``depth`` is greater than zero, then the first output character, and each output character after a newline in a format string, is preceded by ``depth`` spaces. ``WriteF()`` expects a format string followed by zero or more items to insert into the output, followed by another format string, more items, and so on, and finally a ``NULL`` format string. For example:: res = WriteF(stream, depth, "Hello: $A\n", (WriteFA)address, "Spong: $U ($S)\n", (WriteFU)number, (WriteFS)string, NULL); if (res != ResOK) return res; This makes ``Describe()`` methods much easier to write. For example, ``BufferDescribe()`` contains the following code:: res = WriteF(stream, depth, "Buffer $P ($U) {\n", (WriteFP)buffer, (WriteFU)buffer->serial, " class $P (\"$S\")\n", (WriteFP)buffer->class, (WriteFS)buffer->class->name, " Arena $P\n", (WriteFP)buffer->arena, " Pool $P\n", (WriteFP)buffer->pool, " ", buffer->isMutator ? "Mutator" : "Internal", " Buffer\n", " mode $C$C$C$C (TRANSITION, LOGGED, FLIPPED, ATTACHED)\n", (WriteFC)((buffer->mode & BufferModeTRANSITION) ? 't' : '_'), (WriteFC)((buffer->mode & BufferModeLOGGED) ? 'l' : '_'), (WriteFC)((buffer->mode & BufferModeFLIPPED) ? 'f' : '_'), (WriteFC)((buffer->mode & BufferModeATTACHED) ? 'a' : '_'), " fillSize $UKb\n", (WriteFU)(buffer->fillSize / 1024), " emptySize $UKb\n", (WriteFU)(buffer->emptySize / 1024), " alignment $W\n", (WriteFW)buffer->alignment, " base $A\n", (WriteFA)buffer->base, " initAtFlip $A\n", (WriteFA)buffer->initAtFlip, " init $A\n", (WriteFA)buffer->ap_s.init, " alloc $A\n", (WriteFA)buffer->ap_s.alloc, " limit $A\n", (WriteFA)buffer->ap_s.limit, " poolLimit $A\n", (WriteFA)buffer->poolLimit, " alignment $W\n", (WriteFW)buffer->alignment, " rampCount $U\n", (WriteFU)buffer->rampCount, NULL); if (res != ResOK) return res; _`.types`: For each format ``$X`` that ``WriteF()`` supports, there is a type ``WriteFX`` defined in mpmtypes.h, which is the promoted version of that type. These types are provided both to ensure promotion and to avoid any confusion about what type should be used in a cast. It is easy to check the casts against the formats to ensure that they correspond. _`.types.cast`: Every argument to ``WriteF()`` must be cast, because in variable-length argument lists the "default argument promotion" rules apply and this could cause an argument to be read incorrectly on some platforms: for example on a 64-bit platform the ``$W`` format, which expects a 64-bit argument, is incompatible with a 32-bit ``unsigned`` argument, which will not be promoted to 64 bits by the default argument promotion rules. (Note that most of these casts are unnecessary, but requiring them all makes it easy to check that the necessary ones are all there.) _`.types.future`: It is possibly that this type set or similar may be used in future in some generalisation of varargs in the MPS. _`.formats`: The formats supported are as follows. ======= =========== ================== ======================================= Code Name Type Example rendering ======= =========== ================== ======================================= ``$A`` address ``Addr`` ``000000019EF60010`` ``$P`` pointer ``void *`` ``000000019EF60100`` ``$F`` function ``void (*)(void)`` ``0001D69E01000000`` (see `.function`_) ``$S`` string ``char *`` ``hello`` ``$C`` character ``char`` ``x`` ``$W`` word ``ULongest`` ``0000000000109AE0`` ``$U`` decimal ``ULongest`` ``42`` ``$B`` binary ``ULongest`` ``00000000000000001011011110010001`` ``$$`` dollar -- ``$`` ======= =========== ================== ======================================= Note that ``WriteFC`` is an ``int``, because that is the default promotion of a ``char`` (see `.types`_). _`.snazzy`: We should resist the temptation to make ``WriteF()`` an incredible snazzy output engine. We only need it for ``Describe()`` methods. At the moment it's a simple bit of code -- let's keep it that way. _`.function`: The ``F`` code is used for function pointers. The C standard [C1999c]_ defines conversion between pointer-to-function types (§6.3.2.3.8), but it does not define conversion between pointers to functions and pointers to data. To work around this, the bytes of their representation are written sequentially, and may have a different endianness to other pointer types. This output could be smarter, or even look up function names, but see `.snazzy`_. The particular type ``void (*)(void)`` is chosen because in GCC (version 8) this suppresses the warning that we would otherwise get from ``-Wcast-function-type``. See job004156_ and `GCC Warning Options`_. .. _job004156: https://www.ravenbrook.com/project/mps/issue/job004156/ .. _GCC Warning Options: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html References ---------- .. [C1999c] International Standard ISO/IEC 9899:1999; "Programming languages — C"; Document History ---------------- - 1996-10-18 RB_ Incomplete design. - 2002-06-07 RB_ Converted from MMInfo database design document. - 2013-05-22 GDR_ Converted to reStructuredText. - 2014-04-17 GDR_ ``WriteF()`` now takes a ``depth`` parameter. - 2019-03-14 GDR_ Change type of ``WriteFF`` to avoid compiler warning. .. _RB: https://www.ravenbrook.com/consultants/rb/ .. _GDR: https://www.ravenbrook.com/consultants/gdr/ Copyright and License --------------------- Copyright © 2013–2020 `Ravenbrook Limited `_. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.