# Doxyfile 1.8.20 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. # # All text after a double hash (##) is considered a comment and is placed in # front of the TAG it is preceding. # # All text after a single hash (#) is considered a comment and will be ignored. # The format is: # TAG = value [value, ...] # For lists, items can also be appended using: # TAG += value [value, ...] # Values that contain spaces should be placed between quotes (\" \"). #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- # This tag specifies the encoding used for all characters in the configuration # file that follow. The default is UTF-8 which is also the encoding used for all # text before the first occurrence of this tag. Doxygen uses libiconv (or the # iconv built into libc) for the transcoding. See # https://www.gnu.org/software/libiconv/ for the list of possible encodings. # The default value is: UTF-8. DOXYFILE_ENCODING = UTF-8 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by # double-quotes, unless you are using Doxywizard) that should identify the # project for which the documentation is generated. This name is used in the # title of most generated pages and in a few other places. # The default value is: My Project. PROJECT_NAME = fetchmail # The PROJECT_NUMBER tag can be used to enter a project or revision number. This # could be handy for archiving the generated documentation or if some version # control system is used. PROJECT_NUMBER = legacy_64 # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a # quick idea about the purpose of the project. Keep the description short. PROJECT_BRIEF = # With the PROJECT_LOGO tag one can specify a logo or an icon that is included # in the documentation. The maximum height of the logo should not exceed 55 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy # the logo to the output directory. PROJECT_LOGO = # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is # entered, it will be relative to the location where doxygen was started. If # left blank the current directory will be used. OUTPUT_DIRECTORY = dox # If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub- # directories (in 2 levels) under the output directory of each output format and # will distribute the generated files over these directories. Enabling this # option can be useful when feeding doxygen a huge amount of source files, where # putting all generated files in the same directory would otherwise causes # performance problems for the file system. # The default value is: NO. CREATE_SUBDIRS = NO # If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII # characters to appear in the names of generated files. If set to NO, non-ASCII # characters will be escaped, for example _xE3_x81_x84 will be used for Unicode # U+3044. # The default value is: NO. ALLOW_UNICODE_NAMES = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese, # Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States), # Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, # Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), # Korean, Korean-en (Korean with English messages), Latvian, Lithuanian, # Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian, # Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, # Ukrainian and Vietnamese. # The default value is: English. OUTPUT_LANGUAGE = English # The OUTPUT_TEXT_DIRECTION tag is used to specify the direction in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all generated output in the proper direction. # Possible values are: None, LTR, RTL and Context. # The default value is: None. OUTPUT_TEXT_DIRECTION = None # If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member # descriptions after the members that are listed in the file and class # documentation (similar to Javadoc). Set to NO to disable this. # The default value is: YES. BRIEF_MEMBER_DESC = YES # If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief # description of a member or function before the detailed description # # Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. # The default value is: YES. REPEAT_BRIEF = YES # This tag implements a quasi-intelligent brief description abbreviator that is # used to form the text in various listings. Each string in this list, if found # as the leading text of the brief description, will be stripped from the text # and the result, after processing the whole list, is used as the annotated # text. Otherwise, the brief description is used as-is. If left blank, the # following values are used ($name is automatically replaced with the name of # the entity):The $name class, The $name widget, The $name file, is, provides, # specifies, contains, represents, a, an and the. ABBREVIATE_BRIEF = # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then # doxygen will generate a detailed section even if there is only a brief # description. # The default value is: NO. ALWAYS_DETAILED_SEC = NO # If the INLINE_INHERITED_M
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
<title>TRIO</title>
<link href="trio.css" rel="stylesheet" type="text/css">
</head>
<body>
<!-- Generated by Doxygen 1.2.12 -->
<center>
<a class="qindex" href="index.html">Main Page</a> <a class="qindex" href="modules.html">Modules</a> </center>
<hr><h1>TRIO Documentation</h1>
<p>
<dl compact><dt><b>
Author: </b><dd>
Bj�rn Reese , Daniel Stenberg</dl><a name="intro"><h2>Introduction</h2></a>
<p>
Trio is a fully matured and stable set of printf and string functions designed be used by applications with focus on portability or with the need for additional features that are not supported by standard stdio implementation.
<p>
There are several cases where you may want to consider using trio:
<p>
<ul>
<li> Portability across heterogeneous platforms. <li> Embedded systems without stdio support. <li> Extendability of unsupported features. <li> Your native version does not do everything you need.</ul>
When you write applications that must be portable to a wide range of platforms you often have to deal with inadequate implementations of the stdio library functions. Most notably is the lack of secure formatting functions, such as snprintf, or the lack of parameter reordering commonly used for the internationalization of applications, such as the <num>$ modifier. Sometimes the feature you need is simply not present in stdio. So you end up spending much effort on determining which platforms supports what, and to write your own versions of various features. This is where trio can help you. Trio is a platform-independent implementation of the stdio printf and scanf functions and the string library functions.
<p>
The functionality described in the stdio standards is a compromise, and does unfortunately not include a mechanism to extend the functionality for an individual application. Oftentimes an application has the need for an extra feature, and the application code can become much more clear and readable by using an extension mechanism. Trio supports a range of useful extensions such as user-defined specifiers, passing of arguments in arrays, localized string scanning, thousand-separators, and arbitrary integer bases.
<p>
Trio fully implements the C99 (ISO/IEC 9899:1999) and UNIX98 (the Single Unix Specification, Version 2) standards, as well as many features from other implemenations, e.g. the GNU libc and BSD4.
<p>
<a name="examples"><h2>Examples</h2></a>
<p>
<a name="ex1"><h3>Binary Numbers</h3></a>
Output an integer as a binary number using a trio extension. <div class="fragment"><pre>
trio_printf("%..2i\n", number);
</pre></div>
<p>
<a name="ex2"><h3>Thousand-separator</h3></a>
Output a number with thousand-separator using a trio extension. <div class="fragment"><pre>
trio_printf("%'f\n", 12345.6);
</pre></div> The thousand-separator described by the locale is used.
<p>
<a name="ex3"><h3>Fixed Length Array and Sticky Modifier</h3></a>
Output an fixed length array of floating-point numbers. <div class="fragment"><pre>
double array[] = {1.0, 2.0, 3.0};
printf("%.2f %.2f %.2f\n", array[0], array[1], array[2]);
</pre></div> The same with two trio extensions (arguments are passed in an array, and the first formatting specifier sets the sticky option so we do not have to type all the formatting modifiers for the remaining formatting specifiers) <div class="fragment"><pre>
trio_printfv("%!.2f %f %f\n", array);
</pre></div> Another, and more powerful, application of being able to pass arguments in an array is the creation of the printf/scanf statement at run-time, where the formatting string, and thus the argument list, is based on an external configuration file.
<p>
<a name="ex4"><h3>Localized scanning</h3></a>
Parse a string consisting of one or more upper-case alphabetic characters followed by one or more numeric characters. <div class="fragment"><pre>
sscanf(buffer, "%[A-Z]%[0-9]", alphabetic, numeric);
</pre></div> The same but with locale using a trio extension. <div class="fragment"><pre>
trio_sscanf(buffer, "%[[:upper:]]%[[:digit:]]", alphabetic, numeric);
</pre></div>
<p>
<a name="legal"><h2>Legal Issues</h2></a>
Trio is distributed under the following license, which allows practically anybody to use it in almost any kind of software, including proprietary software, without difficulty.
<p>
"Copyright (C) 1998-2001 Bjorn Reese and Daniel Stenberg.
<p>
Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
<p>
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE AUTHORS AND CONTRIBUTORS ACCEPT NO RESPONSIBILITY IN ANY CONCEIVABLE MANNER."
<p>
<a name="contribution"><h2>Contribution</h2></a>
<p>
<a name="contribute"><h3>Contribute</h3></a>
We appreciate any type of contribution, from ideas over improvements to error corrections.
<p>
The project space contains references to bug and feature tracking, mailing-list, and the CVS repository. We prefer communication via the mailing-list, but do not require you to be subscribed, because trio is a small project.
<p>
The project space is located at <a href="http://sourceforge.net/projects/ctrio/">http://sourceforge.net/projects/ctrio/</a>
<p>
<a name="contributors"><h3>Contributors</h3></a>
We have received contributions from the following persons (in alphabetic order sorted by surname)
<p>
<ul>
<li> Craig Berry <li> Stan Boehm <li> Robert Collins <li> Danny Dulai <li> John Fotheringham <li> Markus Henke <li> Ken Gibson <li> Paul Janzen <li> Richard Jinks <li> Tero J�nk� <li> Howard Kapustein <li> Mehdi Lavasani <li> Alexander Lukyanov <li> Emmanuel Mogenet <li> Jacob Navia <li> Jose Ortiz <li> Joe Orton <li> Gisli Ottarsson <li> Marc Werwerft <li> Igor Zlatkovic</ul>
Please let us know, and accept our apology, if we have omitted anybody.
<p>
<HR>
<center class="copyright">Copyright (C) 2001 Bjørn Reese and Daniel Stenberg.</center>
</body>
</html>