1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288128912901291129212931294129512961297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321132213231324132513261327132813291330133113321333133413351336133713381339134013411342134313441345134613471348134913501351135213531354135513561357135813591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513861387138813891390139113921393139413951396139713981399140014011402140314041405140614071408140914101411141214131414141514161417141814191420142114221423142414251426142714281429143014311432143314341435143614371438143914401441144214431444144514461447144814491450145114521453145414551456145714581459146014611462146314641465146614671468146914701471147214731474147514761477147814791480148114821483148414851486148714881489149014911492149314941495149614971498149915001501150215031504150515061507150815091510151115121513151415151516151715181519152015211522152315241525152615271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555155615571558155915601561156215631564156515661567156815691570157115721573157415751576157715781579158015811582158315841585158615871588158915901591159215931594159515961597159815991600160116021603160416051606160716081609161016111612161316141615161616171618161916201621 |
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
- <html>
- <head>
- <title>Ghostscript C coding guidelines</title>
- <!-- $Id: C-style.htm,v 1.55 2005/10/20 19:46:23 ray Exp $ -->
- <!-- Originally: c-style.txt -->
- <link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style">
- </head>
- <body>
- <!-- [1.0 begin visible header] ============================================ -->
- <!-- [1.1 begin headline] ================================================== -->
- <h1>Ghostscript C coding guidelines</h1>
- <!-- [1.1 end headline] ==================================================== -->
- <!-- [1.2 begin table of contents] ========================================= -->
- <h2>Table of contents</h2>
- <blockquote><ul>
- <li><a href="#Introduction">Introduction</a>
- <li><a href="#C_language">C language do's and don'ts</a>
- <ul>
- <li>Preprocessor:
- <a href="#Conditionals">Conditionals</a>,
- <a href="#Macros">Macros</a>,
- <a href="#Preprocessor_other">Other</a>
- <li><a href="#Lexical_elements">Lexical elements</a>
- <li><a href="#Scoping">Scoping</a>
- <li>Data types:
- <a href="#Scalars">Scalars</a>,
- <a href="#Arrays">Arrays</a>,
- <a href="#Typedefs">Typedefs</a>,
- <a href="#Structures">Structures</a>,
- <a href="#Unions">Unions</a>
- <li><a href="#Expressions">Expressions</a>
- <li><a href="#Statements">Statements</a>
- <li><a href="#Procedures">Procedures</a> (prototypes and definitions)
- <li><a href="#Standard_library">Standard library</a>
- </ul>
- <li><a href="#Language_extensions">Language extensions</a>
- <li><a href="#Stylistic_conventions">Stylistic conventions</a>
- <ul>
- <li>Formatting:
- <a href="#Indentation">Indentation</a>,
- <a href="#Spaces">Spaces</a>,
- <a href="#Parentheses">Parentheses</a>
- <li><a href="#Preprocessor_style">Preprocessor</a>
- <li><a href="#Naming">Naming</a>
- <li><a href="#Types">Types</a>
- <li><a href="#Procedures_style">Procedures</a>,
- <li>Miscellany:
- <a href="#Local_variables">Local variables</a>,
- <a href="#Compiler_warnings">Compiler warnings</a>
- </ul>
- <li><a href="#File_structuring">File structuring and naming</a>
- <ul>
- <li><a href="#All_files">All files</a>
- <li><a href="#Makefiles">Makefiles</a>
- <li><a href="#General_C_code">General C Code</a>
- <li><a href="#Headers">Headers (<b><tt>.h</tt></b> files)</a>
- <li><a href="#Source">Source (<b><tt>.c</tt></b> files)</a>
- </ul>
- <li><a href="#Conventions">Ghostscript conventions</a>
- <ul>
- <li><a href="#Specific_names">Specific names</a>:
- <a href="#code"><b><tt>code</tt></b></a>,
- <a href="#status"><b><tt>status</tt></b></a>
- <li><a href="#Structure_type_descriptors">Structure type descriptors</a>
- <li><a href="#Objects">"Objects"</a>
- <li><a href="#Error_handling">Error handling</a>
- </ul>
- </ul></blockquote>
- <!-- [1.2 end table of contents] =========================================== -->
- <!-- [1.3 begin hint] ====================================================== -->
- <p>
- For other information, see the <a href="Readme.htm">Ghostscript
- overview</a>.
- <!-- [1.3 end hint] ======================================================== -->
- <hr>
- <!-- [1.0 end visible header] ============================================== -->
- <!-- [2.0 begin contents] ================================================== -->
- <h2><a name="Introduction"></a>Introduction</h2>
- <p>
- This document describes Ghostscript's C coding conventions. It is primarily
- <em>prescriptive</em>, documenting what developers should do when writing
- new code; the companion developer documentation (<a
- href="Develop.htm">Develop.htm</a>) is primarily <em>descriptive</em>,
- documenting the way things are.
- <p>
- We encourage following the general language usage and stylistic rules for
- any code that will be integrated with Ghostscript, even if the code doesn't
- use Ghostscript's run-time facilities or have anything to do with
- PostScript, PDF, or page description languages. Ghostscript itself follows
- some additional conventions; these are documented separately under "<a
- href="#Conventions">Ghostscript conventions</a>" below.
- <hr>
- <h2><a name="C_language"></a>C language do's and don'ts</h2>
- <p>
- There are several different versions of the C language, and even of the ANSI
- C standard. Ghostscript versions through 7.0 were designed to compile on
- pre-ANSI compilers as well as on many compilers that implemented the ANSI
- standard with varying faithfulness. Ghostscript versions since 7.0 do not
- cater for pre-ANSI compilers: they must conform to the ANSI 1989 standard
- (ANS X3.159-1989), with certain restrictions and a few conventional
- additions.
- <h3>Preprocessor</h3>
- <h4><a name="Conditionals"></a>Conditionals</h4>
- Restrictions:
- <ul>
- <li>Don't assume that <b><tt>#if</tt></b> will treat undefined names as 0.
- While the ANSI standard requires this, it may produce a warning.
- <li>In <b><tt>.c</tt></b> files, don't use preprocessor conditionals that
- test for individual platforms or compilers. Use them only in header files
- named xxx<b><tt>_.h</tt></b>.
- </ul>
- <h4><a name="Macros"></a>Macros</h4>
- <p>
- Restrictions:
- <ul>
- <li>Don't redefine a macro, even with the same definition, without using
- <b><tt>#undef</tt></b>.
- <li><b><tt>CAPITALIZE</tt></b> macro names unless there is a good reason not
- to.
- <li>Even though the legacy code contains some macros which contain
- control flow statments, avoid the use of this in new code and do not
- create macros which contain hidden control flow, especially 'return'.
- The use of control flow in macros complicates debug significantly
- requiring tedious expansion of macros to build a module to be debugged
- or resorting to disassembly windows to set breakpoints or to trace
- flow.
- <li>Don't use a macro call within a macro argument if the call expands to a
- token sequence that includes any commas not within parentheses: this
- produces different results depending on whether the compiler expands the
- inner call before or after the argument is substituted into the macro body.
- (The ANSI standard says that calls must be expanded after substitution, but
- some compilers do it the other way.)
- <li>Don't use macro names, even inadvertently, in string constants. Some
- compilers erroneously try to expand them.
- <li>Don't use macros to define shorthands for casted pointers. For
- instance, avoid
- <blockquote><b><tt>
- #define fdev ((gx_device_fubar *)dev)
- </tt></b></blockquote>
- <p>
- and instead use
- <blockquote><b><tt>
- gx_device_fubar * const fdev = (gx_device_fubar *)dev;
- </tt></b></blockquote>
- <p>
- The use of <b><tt>const</tt></b> alerts the reader that this is effectively
- a synonym.
- <li>If a macro generates anything larger than a single expression (that is,
- one or more statements), surround it with <b><tt>BEGIN</tt></b> and
- <b><tt>END</tt></b>. These work around the fact that simple statements and
- compound statements in C can't be substituted for each other syntactically.
- <li>If a macro introduces local variables, only use names that end with an
- underscore (<b><tt>_</tt></b>), such as <b><tt>code_</tt></b>. This avoids
- clashes both with ordinary variable names (which should never end with an
- underscore) and with system-defined names (which may begin with an
- underscore).
- </ul>
- <h3><a name="Preprocessor_other"></a>Other</h3>
- <p>
- Restrictions:
- <ul>
- <li>Only use <b><tt>#pragma</tt></b> in files that are explicitly identified
- as being platform-dependent. Many compilers complain if this is used at
- all, and some complain if they don't recognize the specific pragma being
- requested (both incorrect according to the ANSI standard).
- </ul>
- <h3><a name="Lexical_elements"></a>Lexical elements</h3>
- <p>
- Do not use:
- <ul>
- <li>ANSI trigraphs (??x)
- <li>Nested comments (/* /* */ */) (not ANSI compliant, but often accepted)
- <li>Multi-character character constants ('abc')
- <li>Wide-character character or string constants (L'x', L"x")
- </ul>
- <p>
- Restrictions:
- <ul>
- <li>Procedure and static variable names must be 31 characters or less.
- <li>Externally visible procedure and variable names must be unique in the
- first 23 characters.
- </ul>
- <h3><a name="Scoping"></a>Scoping (extern, static, ...)</h3>
- <p>
- Do not use:
- <ul>
- <li><b><tt>register</tt></b>
- </ul>
- <p>
- Restrictions:
- <ul>
- <li>Do not allow a global variable (constant) to have more than one
- non-<b><tt>extern</tt></b> definition, even though some ANSI C compilers
- allow this. Every global constant should have exactly one definition, in a
- <b><tt>.c</tt></b> file, and preferably just one <b><tt>extern</tt></b>
- declaration, in a header file.
- <li>Use <b><tt>private</tt></b> instead of <b><tt>static</tt></b> for
- procedures and variables declared at the outermost scope of a file. This
- allows making such constructs either visible or invisible to profilers by
- changing a single <b><tt>#define</tt></b>.
- <li><b><tt>static</tt></b> or <b><tt>private</tt></b> variables must be
- <b><tt>const</tt></b> and initialized: non-<b><tt>const</tt></b> statically
- allocated variables are incompatible with reentrancy, and we're in the
- process of eliminating all of them.
- <li>Do not use <b><tt>extern</tt></b> in <b><tt>.c</tt></b> files, only in
- <b><tt>.h</tt></b> files, unless you have a very good reason for it (e.g.,
- as in <a href="../src/iconf.c">iconf.c</a>). There are too many such
- <b><tt>extern</tt></b>s in the code now: we are eliminating them over time.
- <li>Do not declare the same name as both <b><tt>static</tt></b>
- (<b><tt>private</tt></b>) and non-<b><tt>static</tt></b> within the same
- compilation. (Some compilers complain, some do not.) This is especially a
- problem for procedures: it is easy to declare a procedure as
- <b><tt>private</tt></b> near the beginning of a file and accidentally not
- declare it <b><tt>private</tt></b> where it is defined later in the file.
- <li>Even though the ANSI standard allows initialized external declarations
- (<b><tt>extern int x = 0</tt></b>), don't use them.
- </ul>
- <h3><a name="Scalars"></a>Scalars</h3>
- <p>
- Restrictions:
- <ul>
- <li>Avoid using <b><tt>char</tt></b>, except for <b><tt>char *</tt></b>
- for a pointer to a string. Don't assume that <b><tt>char</tt></b> is
- signed; also don't assume it is unsigned.
- <li>Never cast a <b><tt>float</tt></b> to a <b><tt>double</tt></b>
- explicitly. ANSI compilers in their default mode do all floating point
- computations in double precision, and handle such casts automatically.
- <li>Don't use <b><tt>long long</tt></b>: even though it is in the ANSI
- standard, not all compilers support it. Use <b><tt>bits64</tt></b> instead
- (see below under "<a href="#Language_extensions">Language extensions</a>").
- <li>Don't assume anything about whether <b><tt>sizeof(long)</tt></b> is less
- than, equal to, or greater than <b><tt>sizeof(ptr)</tt></b>. (However, you
- can make such comparisons in preprocessor conditionals using
- <b><tt>ARCH_SIZEOF_LONG</tt></b> and <b><tt>ARCH_SIZEOF_PTR</tt></b>.)
- </ul>
- <h3><a name="Arrays"></a>Arrays</h3>
- <p>
- Restrictions:
- <ul>
- <li>Don't declare arrays of size 0. (The newer ANSI standard allows this,
- but the older one doesn't.)
- <li>Don't declare an array of size 1 at the end of a structure to indicate
- that a variable-size array follows.
- <li>Don't declare initialized <b><tt>auto</tt></b> arrays.
- </ul>
- <h3><a name="Typedefs"></a>Typedefs</h3>
- <p>
- Restrictions:
- <ul>
- <li>Don't use <b><tt>typedef</tt></b> for function types, such as
- <blockquote>
- <b><tt>typedef int proc_xyz_t(double, int *);</tt></b>
- </blockquote>
- <p>Many compilers don't handle this correctly -- they will give errors, or
- do the wrong thing, when declaring variables of type
- <b><tt>proc_xyz_t</tt></b> and/or <b><tt>proc_xyz_t *</tt></b>. Instead, do
- this:
- <blockquote>
- <b><tt>#define PROC_XYZ(proc) int proc(double, int *)<br>
- PROC_XYZ(some_proc); /* declare a procedure of this type */<br>
- typedef PROC_XYZ((*proc_xyz_ptr_t)); /* define a type for procedure ptrs */<br>
- <br>
- proc_xyz_ptr_t pp; /* pointer to procedure */</tt></b>
- </blockquote>
- <li>Don't redefine <b><tt>typedef</tt></b>'ed names, even with the same
- definition. Some compilers complain about this, and the standard doesn't
- allow it.
- </ul>
- <h3><a name="Structures"></a>Structures</h3>
- <p>
- Restrictions:
- <ul>
- <li>Don't use anonymous structures if you can possibly avoid it, except
- occasionally as components of other structures. Ideally, use the
- <b><tt>struct</tt></b> keyword only for declaring named structure types,
- like this:
- <blockquote>
- <b><tt>typedef struct xxx_s {</tt></b><br>
- ... members ...<br>
- <b><tt>} xxx_t;</tt></b>
- </blockquote>
- <li>Use <b><tt>struct</tt></b> only when declaring structure types, never
- for referring to them (e.g., never declare a variable as type
- <b><tt>struct xxx_s *</tt></b>).
- <li>Don't assume that the compiler will (or won't) insert padding in
- structures to align members for best performance. To preserve alignment,
- only declare structure members that are narrower than an <b><tt>int</tt></b>
- if there will be a lot of instances of that structure in memory. For such
- structures, insert <b><tt>byte</tt></b> and/or <b><tt>short</tt></b> padding
- members as necessary to re-establish <b><tt>int</tt></b> alignment.
- <li>Don't declare initialized <b><tt>auto</tt></b> structures.
- </ul>
- <h3><a name="Unions"></a>Unions</h3>
- <p>
- Restrictions:
- <ul>
- <li>Use unions only as components of structures, not as typedefs in their
- own right.
- <li>Don't attempt to initialize unions: not all compilers support this, even
- though it is in the 1989 ANSI standard.
- </ul>
- <h3><a name="Expressions"></a>Expressions</h3>
- <p>
- Restrictions:
- <ul>
- <li>Don't assign a larger integer data type to a smaller one without a cast
- (<b><tt>int_x = long_y</tt></b>).
- <li>It's OK to use the address of a structure or array element
- (<b><tt>&p->e</tt></b>, <b><tt>&a[i]</tt></b>) locally, or pass it to a
- procedure that won't store it, but don't store such an address in allocated
- storage unless you're very sure of what you're doing.
- <li>Don't use conditional expressions with structure or union values.
- (Pointers to structures or unions are OK.)
- <li>For calling a variable or parameter procedure, use
- <b><tt>ptr->func(...)</tt></b>. Some old code uses explicit indirection,
- <b><tt>(*ptr->func)(...)</tt></b>: don't use this in new code.
- <li>Don't write expressions that depend on order of evaluation, unless the
- order is created explicitly by use of <b><tt>||</tt></b>,
- <b><tt>&&</tt></b>, <b><tt>?:</tt></b>, <b><tt>,</tt></b>, or
- function nesting (the arguments of a function must be evaluated before the
- function is called). In particular, don't assume that the arguments of a
- function will be evaluated left-to-right, or that the left side of an
- assignment will be evaluated before the right.
- <li>Don't mix integer and enumerated types ad lib: treat enumerated types as
- distinct from integer types, and use casts to convert between the two.
- (Some compilers generate warnings if you do not do this.)
- </ul>
- <h3><a name="Statements"></a>Statements</h3>
- <p>
- Restrictions:
- <ul>
- <li>If you use an expression as a statement, other than an assignment or a
- function call with <b><tt>void</tt></b> return value, enclose it explicitly
- in <b><tt>DISCARD()</tt></b>.
- <li>The type of the operand of a <b><tt>switch</tt></b> must match the type
- of the case labels, whether the labels are <b><tt>int</tt></b>s or the
- members of an <b><tt>enum</tt></b> type. (Use a cast if necessary.)
- <li>It is OK for one case of a switch to "fall through" into another (i.e.,
- for the statement just before a case label not to be a control transfer),
- but a comment <b><tt>/* falls through */</tt></b> is
- required.
- <li>If you are returning an error code specified explicitly (e.g.,
- <b><tt>return gs_error_rangecheck</tt></b> or
- <b><tt>return e_rangecheck</tt></b>), use
- <b><tt>return_error()</tt></b> rather than plain <b><tt>return</tt></b>.
- However, if the program is simply propagating an error code generated
- elsewhere, as opposed to generating the error, use <b><tt>return</tt></b>
- (e.g., <b><tt>if (code < 0) return code</tt></b>).
- </ul>
- <h3><a name="Procedures"></a>Procedures</h3>
- <p>
- Restrictions:
- <ul>
- <li>Provide a prototype for every procedure, and make sure the prototype is
- available at every call site. If the procedure is local to a file
- (<b><tt>private</tt></b>), the prototype should precede the procedure, in
- the same file; if the procedure is global, the prototype should be in a
- header file.
- <li>If a procedure parameter is itself a procedure, do list its parameter
- types rather than just using <b><tt>()</tt></b>. For example,
- <blockquote><b><tt>
- int foo(int (*callback)(int, int));
- </tt></b></blockquote>
- <p>
- rather than just
- <blockquote><b><tt>
- int foo(int (*callback)());
- </tt></b></blockquote>
- <li>Don't use the <b><tt>P</tt></b>* macros in new code. (See the
- Procedures section of <a href="#Language_extensions">Language extensions</a>
- below for more information.)
- <li>Always provide an explicit return type for procedures, in both the
- prototype and the definition: don't rely on the implicit declaration as
- <b><tt>int</tt></b>.
- <li>Don't use <b><tt>float</tt></b> as the return type of a procedure,
- unless there's a special reason. Floating point hardware typically does
- everything in double precision internally and has to do extra work to
- convert between double and single precision.
- <li>Don't declare parameters as being of type <b><tt>float</tt></b>,
- <b><tt>short</tt></b>, or <b><tt>char</tt></b>. If you do this and forget
- to include the prototype at a call site, ANSI compilers will generate
- incompatible calling sequences. Use <b><tt>floatp</tt></b> (a synonym for
- <b><tt>double</tt></b>, mnemonic for "float parameter") instead of
- <b><tt>float</tt></b>, and use <b><tt>int</tt></b> or <b><tt>uint</tt></b>
- instead of <b><tt>short</tt></b> or <b><tt>char</tt></b>.
- </ul>
- <h3><a name="Standard_library"></a>Standard library</h3>
- <p>
- Restrictions:
- <ul>
- <li>Only use library features that are documented in the established ANSI
- standard (e.g., Harbison & Steele's book). Do not use procedures that are
- "standards" promulgated by Microsoft (e.g., <b><tt>stricmp</tt></b>), or
- originate in BSD Unix (e.g., <b><tt>strcasecmp</tt></b>), or were added in
- later versions of the standard such as C 9X.
- <li>Do not use any features from <b><tt>stdio.h</tt></b> that assume the
- existence of <b><tt>stdin</tt></b>, <b><tt>stdout</tt></b>, or
- <b><tt>stderr</tt></b>. See <a href="../src/gsio.h">gsio.h</a> for the full
- list. Instead, use <b><tt>gs_stdin</tt></b> et al.
- </ul>
- <hr>
- <h2><a name="Language_extensions"></a>Language extensions</h2>
- <h3>Scoping</h3>
- <dl>
- <dt><b><tt>inline</tt></b>
- <dd><b><tt>inline</tt></b> is available even if the compiler does not
- support it. Be aware, however, that it may have no effect. In particular,
- do not use <b><tt>inline</tt></b> in header files. Instead, use the
- <b><tt>extern_inline</tt></b> facility described just below.
- <dt><b><tt>extern_inline</tt></b>
- <dd>Compilers that do support <b><tt>inline</tt></b> vary in how they decide
- whether to (also) compile a closed-code copy of the procedure. Because of
- this, putting an <b><tt>inline</tt></b> procedure in a header file may
- produce multiple closed copies, causing duplicate name errors at link time.
- <b><tt>extern_inline</tt></b> provides a safe way to put
- <b><tt>inline</tt></b> procedures in header files, regardless of compiler.
- Unfortunately, the only way we've found to make this fully portable involves
- a fair amount of boilerplate. For details, please see <a
- href="../src/stdpre.h">stdpre.h</a>.
- <dt><b><tt>private</tt></b>
- <dd><b>Use <tt>private</tt></b> instead of <b><tt>static</tt></b> for all
- file-local procedures, and also for file-local variables defined at the
- outermost level. However, use <b><tt>static</tt></b>, not
- <b><tt>private</tt></b>, for variables defined within a procedure.
- <p>
- <b><tt>private</tt></b> is normally #define'd as <b><tt>static</tt></b>.
- However, it can also be #define'd as empty, which allows profilers to
- measure all procedures, and 'nm' to list all interesting statically
- allocated variables, not just public ones.
- </dl>
- <h3>Scalar types</h3>
- <dl>
- <dt><b><tt>bool, true, false</tt></b>
- <dd><b><tt>bool</tt></b> is intended as a Boolean type, with canonical
- values <b><tt>true</tt></b> and <b><tt>false</tt></b>. In a more reasonable
- language, such as Java, <b><tt>bool</tt></b> is an enumerated type requiring
- an explicit cast to or from <b><tt>int</tt></b>; however, because C's
- conditionals are defined as producing <b><tt>int</tt></b> values, we can't
- even define <b><tt>bool</tt></b> as a C <b><tt>enum</tt></b> without
- provoking compiler warnings.
- <p>
- Even though <b><tt>bool</tt></b> is a synonym for <b><tt>int</tt></b>, treat
- them as conceptually different types:
- <ul>
- <li>Initialize or set <b><tt>bool</tt></b> variables to <b><tt>true</tt></b>
- or <b><tt>false</tt></b>, not 0 or 1.
- <li>Use the Boolean operators <b><tt>!</tt></b>, <b><tt>&&</tt></b>,
- and <b><tt>||</tt></b> only with Booleans. Don't use the idiom
- <b><tt>!!x</tt></b> to create a Boolean that is true iff <b><tt>x</tt></b>
- != 0: use <b><tt>x != 0</tt></b>.
- <li>Use an explicit <b><tt>(int)</tt></b> cast to convert a Boolean to an
- integer.
- </ul>
- <dt><b><tt>byte, ushort, uint, ulong</tt></b>
- <dd>These types are simply shorthands for <b><tt>unsigned char, short, int,
- long</tt></b>.
- <p>
- In addition, the use of <b><tt>byte *</tt></b> indicates a
- Ghostscript-style string, with explicit length given separately, as
- opposed to a null terminated C-style string, which is <b><tt>char
- *</tt></b>.
- <dt><b><tt>floatp</tt></b>
- <dd>This is a synonym for <b><tt>double</tt></b>. It should be used for,
- and only for, procedure parameters that would otherwise be
- <b><tt>float</tt></b>. (As noted above, procedure parameters should not be
- declared as <b><tt>float</tt></b>.)
- <dt><b><tt>bits8, bits16, bits32</tt></b>
- <dd>These are unsigned integer types of the given width. Use them wherever
- the actual width matters: do <em>not</em>, for example, use
- <b><tt>short</tt></b> assuming that it is 16 bits wide.
- <dt><b><tt>bits64</tt></b>
- <dd><strong>****** NOT IMPLEMENTED YET ******</strong>
- This is an unsigned 64-bit integer type, but it may not be available on all
- platforms. Any code that uses this type should be surrounded by
- <b><tt>#if ARCH_HAS_BITS64</tt></b>.
- </dl>
- <hr>
- <h2><a name="Stylistic_conventions"></a>Stylistic conventions</h2>
- <p>
- Ghostscript's coding rules cover not only the use of the language, but also
- many stylistic issues like the choice of names and the use of whitespace.
- The stylistic rules are meant to produce code that is easy to read. It's
- important to observe them as much as possible in order to maintain a
- consistent style, but if you find these rules getting in your way or
- producing ugly-looking results once in a while, it's OK to break it.
- <h3><a name="Formatting"></a>Formatting</h3>
- <h4><a name="Indentation"></a>Indentation</h4>
- <p>
- We've formatted all of our code using the GNU <b><tt>indent</tt></b> program.
- <blockquote><b><tt>
- indent -bad -nbap -nsob -br -ce -cli4 -npcs -ncs \<br>
- -i4 -di0 -psl -lp -lps somefile.c
- </tt></b></blockquote>
- <p>
- does a 98% accurate job of producing our preferred style. Unfortunately,
- there are bugs in all versions of GNU <b><tt>indent</tt></b>, requiring
- both pre- and post-processing of the code. The <b><tt>gsindent</tt></b>
- script in the Ghostscript fileset contains the necessary workarounds.
- <p>
- Put indentation points every 4 spaces, with 8 spaces = 1 tab stop.
-
- <p>
- Don't indent the initial <b><tt>#</tt></b> of preprocessor commands.
- However, for nested preprocessor commands, do use indentation between the
- <b><tt>#</tt></b> and the command itself. Use 2 spaces per level of
- nesting, e.g.:
- <blockquote>
- <b><tt>#ifndef xyz</tt></b><br>
- <b><tt># define xyz 0</tt></b><br>
- <b><tt>#endif</tt></b>
- </blockquote>
- <p>
- For assignments (including chain assignments), put the entire statement on
- one line if it will fit; if not, break it after a <b><tt>=</tt></b> and
- indent all the following lines. I.e., format like this:
- <blockquote>
- var1 <b><tt>=</tt></b> value<b><tt>;</tt></b><br>
- var1 <b><tt>=</tt></b> var2 <b><tt>=</tt></b> value<b><tt>;</tt></b><br>
- var1 <b><tt>=</tt></b><br>
- value<b><tt>;</tt></b><br>
- var1 <b><tt>=</tt></b><br>
- var2 <b><tt>=</tt></b> value<b><tt>;</tt></b><br>
- var1 <b><tt>=</tt></b> var2 <b><tt>=</tt></b><br>
- value<b><tt>;</tt></b>
- </blockquote>
- <p>
- But not like this:
- <blockquote>
- var1 <b><tt>=</tt></b><br>
- var2 <b><tt>=</tt></b> value<b><tt>;</tt></b>
- </blockquote>
- <p>
- Indent in-line blocks thus:
- <blockquote>
- <b><tt>{</tt></b><br>
- ... declarations ...<br>
- {{ blank line if any declarations above }}<br>
- ... statements ...<br>
- <b><tt>}</tt></b>
- </blockquote>
- <p>
- Similarly, indent procedures thus:
- <blockquote>
- return_type<br>
- proc_name(... arguments ...)<br>
- <b><tt>{</tt></b><br>
- ... declarations ...<br>
- {{ blank line if any declarations above }}<br>
- ... statements ...<br>
- <b><tt>}</tt></b>
- </blockquote>
- <p>
- If a control construct (<b><tt>if</tt></b>, <b><tt>do</tt></b>,
- <b><tt>while</tt></b>, or <b><tt>for</tt></b>) has a one-line body, use
- this:
- <blockquote>
- ... control construct ...<br>
- ... subordinate simple statement ...
- </blockquote>
- <p>
- If it has a multi-line body, use this:
- <blockquote>
- ... control construct ... <b><tt>{</tt></b><br>
- ... subordinate code ...<br>
- <b><tt>}</tt></b>
- </blockquote>
- <p>
- If the subordinate code has declarations, see blocks above.
- <p>
- For if-else statements, do this:
- <blockquote>
- <b><tt>if (</tt></b> ...<b><tt> ) {</tt></b><br>
- ... subordinate code ...<br>
- <b><tt>} else if (</tt></b> ...<b><tt> ) {</tt></b><br>
- ... subordinate code ...<br>
- <b><tt>} else {</tt></b><br>
- ... subordinate code ...<br>
- <b><tt>}</tt></b>
- </blockquote>
- <p>
- When there are more than two alternatives, as in the example above, use the
- above ("parallel") syntax rather than the following ("nested") syntax:
- <blockquote>
- <b><tt>if (</tt></b> ...<b><tt> ) {</tt></b><br>
- ... subordinate code ...<br>
- <b><tt>} else {</tt></b><br>
- <b><tt> if (</tt></b> ...<b><tt> ) {</tt></b><br>
- ... subordinate code ...<br>
- <b><tt> } else {</tt></b><br>
- ... subordinate code ...<br>
- <b><tt> }</tt></b><br>
- <b><tt>}</tt></b>
- </blockquote>
- <p>
- Similarly, for do-while statements, do this:
- <blockquote>
- <b><tt>do {</tt></b><br>
- ... body ...<br>
- <b><tt>} while (</tt></b> ... condition ... <b><tt>);</tt></b>
- </blockquote>
- <h4><a name="Spaces"></a>Spaces</h4>
- <p>
- Do put a space:
- <ul>
- <li>after every comma and semicolon, unless it ends a line;
- <li>around every binary operator other than "<b><tt>-></tt></b>" and
- "<b><tt>.</tt></b>", although you can omit the spaces around the innermost
- operator in a nested expression if you like;
- <li>on both sides of the parentheses of an <b><tt>if</tt></b>, <b><tt>for</tt></b>, or <b><tt>while</tt></b>.
- </ul>
- <p>
- Don't put a space:
- <ul>
- <li>at the end of a line;
- <li>before a comma or semicolon;
- <li>after unary prefix operators;
- <li>before the parenthesis of a macro or procedure call.
- </ul>
- <h4><a name="Parentheses"></a>Parentheses</h4>
- <p>
- Parentheses are important in only a few places:
- <ul>
- <li>Around the inner subexpressions in expressions that mix
- <b><tt>&&</tt></b> and <b><tt>||</tt></b>, even if they are not
- required by precedence, for example
- <blockquote><b><tt>
- (xx && yy) || zz
- </tt></b></blockquote>
- <li>Similarly around inner subexpressions in expressions that mix
- <b><tt>&</tt></b>, <b><tt>|</tt></b>, or shifts, especially if mixing
- these with other operators, for instance
- <blockquote><b><tt>
- (x << 3) | (y >> 5)
- </tt></b></blockquote>
- <li>In macro definitions around every use of an argument that logically
- could be an expression, for example
- <blockquote><b><tt>
- ((x) * (x) + (y) * (y))
- </tt></b></blockquote>
- </ul>
- <p>
- Anywhere else, given the choice, use fewer parentheses.
- <p>
- For stylistic consistency with the existing Ghostscript code, put
- parentheses around conditional expressions even if they aren't
- syntactically required, unless you really dislike doing this. Note that
- the parentheses should go around the entire expression, not the condition.
- For instance, instead of
- <blockquote><b><tt>
- hpgl_add_point_to_path(pgls, arccoord_x, arccoord_y,<br>
- (pgls->g.pen_down) ? gs_lineto : gs_moveto);
- </tt></b></blockquote>
- <p>
- use
- <blockquote><b><tt>
- hpgl_add_point_to_path(pgls, arccoord_x, arccoord_y,<br>
- (pgls->g.pen_down ? gs_lineto : gs_moveto));
- </tt></b></blockquote>
- <h3><a name="Preprocessor_style"></a>Preprocessor</h3>
- <h4>Conditionals</h4>
- <p>
- Using preprocessor conditionals can easily lead to unreadable code, since
- the eye really wants to read linearly rather than having to parse the
- conditionals just to figure out what code is relevant. It's OK to use
- conditionals that have small scope and that don't change the structure or
- logic of the program (typically, they select between different sets of
- values depending on some configuration parameter), but where possible, break
- up source modules rather than use conditionals that affect the structure or
- logic.
- <h4>Macros</h4>
- <p>
- Ghostscript code uses macros heavily to effectively extend the rather
- weak abstraction capabilities of the C language, specifically in the area of
- memory management and garbage collection: in order to read Ghostscript code
- effectively, you simply have to learn some of these macros as though they
- were part of the language. The current code also uses macros heavily for
- other purposes, but we are trying to phase these out as rapidly as possible,
- because they make the code harder to read and debug, and to use the
- rules that follow consistently in new code.
- <p>
- Define macros in the smallest scope you can manage (procedure, file, or
- <b><tt>.h</tt></b> file), and <b><tt>#undef</tt></b> them at the end of
- that scope: that way, someone reading the code can see the definitions
- easily when reading the uses. If that isn't appropriate, define them in as
- large a scope as possible, so that they effectively become part of the
- language. This places an additional burden on the reader, but it can be
- amortized over reading larger amounts of code.
- <p>
- Try hard to use procedures instead of macros. Use "<b><tt>inline</tt></b>"
- if you really think the extra speed is needed, but only within a
- <b><tt>.c</tt></b> file: don't put inline procedures in <b><tt>.h</tt></b>
- files, because most compilers don't honor "<b><tt>inline</tt></b>" and
- you'll wind up with a copy of the procedure in every <b><tt>.c</tt></b>
- file that includes the <b><tt>.h</tt></b> file.
- <p>
- If you define a macro that looks like a procedure, make sure it will work
- wherever a procedure will work. In particular, put parentheses around every
- use of an argument within the macro body, so that the macro will parse
- correctly if some of the arguments are expressions, and put parentheses
- around the entire macro body. (This is still subject to the problem that an
- argument may be evaluated more than once, but there is no way around this in
- C, since C doesn't provide for local variables within expressions.)
- <p>
- If you define macros for special loop control structures, make their uses
- look somewhat like ordinary loops, for instance:
- <blockquote>
- <b><tt>BEGIN_RECT(xx, yy) {</tt></b><br>
- ... body indented one position ...<br>
- <b><tt>} END_RECT(xx, yy);</tt></b>
- </blockquote>
- <p>
- If at all possible, don't use free variables in macros -- that is, variables
- that aren't apparent as arguments of the macro. If you must use free
- variables, list them all in a comment at the point where the macro is
- defined.
- <p>
- If you define new macros or groups of macros, especially if they aren't
- simply inline procedures or named constant values, put some extra effort
- into documenting them, to compensate for the fact that macros are
- intrinsically harder to understand than procedures.
- <h3><a name="Comments"></a>Comments</h3>
- <p>
- The most important descriptive comments are ones in header files that
- describe structures, including invariants; but every procedure or structure
- declaration, or group of other declarations, should have a comment. Don't
- spend a lot of time commenting executable code unless something unusual or
- subtle is going on.
- <h3><a name="Naming"></a>Naming</h3>
- <p>
- Use fully spelled-out English words in names, rather than contractions.
- This is most important for procedure and macro names, global variables and
- constants, values of <b><tt>#define</tt></b> and <b><tt>enum</tt></b>,
- <b><tt>struct</tt></b> and other <b><tt>typedef</tt></b> names, and
- structure member names, and for argument and variable names which have
- uninformative types like <b><tt>int</tt></b>. It's not very important for
- arguments or local variables of distinctive types, or for local index or
- count variables.
- <p>
- Avoid names that run English words together:
- "<b><tt>hpgl_compute_arc_center</tt></b>" is better than
- "<b><tt>hpgl_compute_arccenter</tt></b>". However, for terms drawn from
- some predefined source, like the names of PostScript operators, use a term
- in its well-known form (for instance, <b><tt>gs_setlinewidth</tt></b>
- rather than <b><tt>gs_set_line_width</tt></b>).
- <p>
- Procedures, variables, and structures visible outside a single
- <b><tt>.c</tt></b> file should generally have prefixes that indicate what
- subsystem they belong to (in the case of Ghostscript, <b><tt>gs_</tt></b>
- or <b><tt>gx_</tt></b>). This rule isn't followed very consistently.
- <h3><a name="Types"></a>Types</h3>
- <p>
- Many older structure names don't have <b><tt>_t</tt></b> on the end, but
- this suffix should be used in all new code. (The <b><tt>_s</tt></b>
- structure name is needed only to satisfy some debuggers. No code other than
- the structure declaration should refer to it.)
- <p>
- Declare structure types that contain pointers to other instances of
- themselves like this:
- <blockquote>
- <b><tt>typedef struct xxx_s xxx_t;</tt></b><br>
- <b><tt>struct xxx_s {</tt></b><br>
- ... members ...<br>
- <b><tt>xxx_t *</tt></b>ptr_member_name;<br>
- ... members ...<br>
- <b><tt>};</tt></b>
- </blockquote>
- <p>
- If, to maintain data abstraction and avoid including otherwise unnecessary
- header files, you find that you want the type <b><tt>xxx_t</tt></b> to be
- available in a header file that doesn't include the definition of the
- structure <b><tt>xxx_s</tt></b>, use this approach:
- <blockquote>
- <b><tt>#ifndef xxx_DEFINED</tt></b><br>
- <b><tt># define xxx_DEFINED</tt></b><br>
- <b><tt>typedef struct xxx_s xxx_t;</tt></b><br>
- <b><tt>#endif</tt></b><br>
- <b><tt>struct xxx_s {</tt></b><br>
- ... members ...<br>
- <b><tt>};</tt></b>
- </blockquote>
- <p>
- You can then copy the first 4 lines in other header files. (Don't ever
- include them in an executable code file.)
- <p>
- Don't bother using <b><tt>const</tt></b> for anything other than with
- pointers as described below. However, in those places where it is necessary
- to cast a pointer of type <b><tt>const T *</tt></b> to type
- <b><tt>T *</tt></b>, always include a comment that explains why you are
- "breaking const".
- <h4>Pointers</h4>
- <p>
- Use <b><tt>const</tt></b> for pointer referents (that is,
- <b><tt>const T *</tt></b>) wherever possible and appropriate.
- <p>
- If you find yourself wanting to use <b><tt>void *</tt></b>, try to
- find an alternative using unions or (in the case of super- and subclasses)
- casts, unless you're writing something like a memory manager that really
- treats memory as opaque.
- <h3><a name="Procedures_style"></a>Procedures</h3>
- <p>
- In general, don't create procedures that are private and only called from
- one place. However, if a compound statement (especially an arm of a
- conditional) is too long for the eye easily to match its enclosing braces
- "<b><tt>{...}</tt></b>" -- that is, longer than 10 or 15 lines -- and it
- doesn't use or set a lot of state held in outer local variables, it may be
- more readable if you put it in a procedure.
- <h3>Miscellany</h3>
- <h4><a name="Local_variables"></a>Local variables</h4>
- <p>
- Don't assign new values to procedure parameters. It makes debugging very
- confusing when the parameter values printed for a procedure are not the
- ones actually supplied by the caller. Instead use a separate local
- variable initialized to the value of the parameter.
- <p>
- If a local variable is only assigned a value once, assign it that value at
- its declaration, if possible. For example,
- <blockquote>
- <b><tt>int x = </tt></b>some expression <b><tt>;</tt></b>
- </blockquote>
- <p>
- rather than
- <blockquote>
- <b><tt>int x;</tt></b><br>
- ...<br>
- <b><tt>x = </tt></b> some expression <b><tt>;</tt></b>
- </blockquote>
- <p>
- Use a local pointer variable like this to "narrow" pointer types:
- <blockquote>
- <b><tt>int</tt></b><br>
- someproc(... <b><tt>gx_device *dev</tt></b> ...)<br>
- <b><tt>{<br>
- gx_device_printer *const pdev = (gx_device_printer *)dev;</tt></b><br>
- ...<br>
- <b><tt>}</tt></b>
- </blockquote>
- <p>
- Don't "shadow" a local variable or procedure parameter with an inner local
- variable of the same name. I.e., don't do this:
- <blockquote>
- <b><tt>int</tt></b><br>
- someproc(... <b><tt>int x</tt></b> ...)<br>
- <b><tt>{</tt></b><br>
- ...<br>
- <b><tt> int x;</tt></b><br>
- ...<br>
- <b><tt>}</tt></b>
- </blockquote>
- <h4><a name="Compiler_warnings"></a>Compiler warnings</h4>
- <p>
- The following section refers to the warnings produced by <b><tt>gcc</tt></b>:
- your compiler may produce different ones.
- <p>
- It's OK if compilation produces the following warnings:
- <ul>
- <li><b><tt><name> might be used uninitialized in this function</tt></b>
- <li><b><tt>cast discards `const' from pointer target type</tt></b>
- </ul>
- <p>
- The first of these often occurs because the compiler isn't aware of control
- flow restrictions that guarantee the variable will be initialized before
- use: if it occurs in new code, check the code carefully, but don't worry
- about the message. The second is often unavoidable in code that initializes
- or frees a structure that is otherwise <b><tt>const</tt></b> during its
- lifetime.
- <p>
- Do work hard to eliminate all warnings other than these,
- since they often indicate the possible presence of coding errors.
- In particular, get rid of warnings about parameter passing or
- initialization that discards <b><tt>const</tt></b>,
- by using explicit casts.
- <hr>
- <h2><a name="File_structuring"></a>File structuring</h2>
- <h3><a name="All_files"></a>All files</h3>
- <p>
- Keep file names within the "8.3" format for portability:
- <ul>
- <li>Use only letters, digits, dash, and underscore in file names.
- <li>Don't assume upper and lower case letters are distinct.
- <li>Put no more than 8 characters before the ".", if any.
- <li>If there is a ".", put between 1 and 3 characters after the ".".
- </ul>
- <p>
- For files other than documentation files, use only lower case letters
- in the names; for HTML documentation files, capitalize the first letter.
- <p>
- Every code file should start with comments containing
- <ol>
- <li>a copyright notice,
- <li>the name of the file in the form of an RCS Id:
- <blockquote><b><tt>
- /* $<!-- -->Id: filename.ext $*/
- </tt></b></blockquote>
- <p>
- (using the comment convention appropriate to the language of the file), and
- <li>a summary, no more than one line, of what the file contains.
- </ol>
- <p>
- If you create a file by copying the beginning of another file, be sure to
- update the copyright year and change the file name.
- <h3><a name="Makefiles"></a>Makefiles</h3>
- <p>
- Use the extension <b><tt>.mak</tt></b> for makefiles.
- <p>
- For each
- <blockquote><b><tt>
- #include "xxx.h"
- </tt></b></blockquote>
- <p>
- make sure there is a dependency on <b><tt>$(xxx_h)</tt></b> in the
- makefile. If xxx ends with a "<b><tt>_</tt></b>", this rule still holds,
- so that if you code
- <blockquote><b><tt>
- #include "math_.h"
- </tt></b></blockquote>
- <p>
- the makefile must contain a dependency on "<b><tt>$(math__h)</tt></b>"
- (note the two underscores "<b><tt>__</tt></b>").
- <p>
- List the dependencies bottom-to-top, like the <b><tt>#include</tt></b>
- statements themselves; within each level, list them alphabetically. Do
- this also with <b><tt>#include</tt></b> statements themselves whenever
- possible (but sometimes there are inter-header dependencies that require
- bending this rule).
- <p>
- For compatibility with the build utilities on OpenVMS, always put a space
- before the colon that separates the target(s) of a rule from the dependents.
- <h3><a name="General_C_code"></a>General C code</h3>
- <p>
- List <b><tt>#include</tt></b> statements from "bottom" to "top", that is,
- in the following order:
- <blockquote><ol>
- <li>System includes (<b><tt>"xxx_.h"</tt></b>)
- <li><b><tt>gs*.h</tt></b>
- <li><b><tt>gx*.h</tt></b> (yes, <b><tt>gs</tt></b> and <b><tt>gx</tt></b>
- are in the wrong order.)
- <li><b><tt>s*.h</tt></b>
- <li><b><tt>i*.h</tt></b> (or other interpreter headers that don't start
- with "<b><tt>i</tt></b>")
- </ol></blockquote>
- <h3><a name="Headers"></a>Headers (<b><tt>.h</tt></b> files)</h3>
- <p>
- In header files, always use the following at the beginning of a header file
- to prevent double inclusion:
- <blockquote>
- {{ Copyright notice etc. }}<br><br>
- <b><tt>#ifndef </tt></b><filename><b><tt>_INCLUDED</tt></b><br>
- <b><tt>#define </tt></b><filename><b><tt>_INCLUDED</tt></b><br><br>
- {{ The contents of the file }}<br><br>
- <b><tt>#endif /* </tt></b><filename><b><tt>_INCLUDED */</tt></b>
- </blockquote>
- <p>
- The header file is the first place that a reader goes for
- information about procedures, structures, constants, etc., so ensure that
- every procedure and structure has a comment that says what it does. Divide
- procedures into meaningful groups set off by some distinguished form of
- comment.
- <h3><a name="Source"></a>Source (<b><tt>.c</tt></b> files)</h3>
- <p>
- After the initial comments, arrange C files in the following order:
- <blockquote><ol>
- <li><b><tt>#include</tt></b> statements
- <li>Exported data declarations
- <li>Explicit externs (if necessary)
- <li>Forward declarations of procedures
- <li>Private data declarations
- <li>Exported procedures
- <li>Private procedures
- </ol></blockquote>
- <p>
- Be flexible about the order of the declarations if necessary to improve
- readability. Many older files don't follow this order, often without good
- reason.
- <hr>
- <h2><a name="Conventions"></a>Ghostscript conventions</h2>
- <h3><a name="Specific_names"></a>Specific names</h3>
- <p>
- The Ghostscript code uses certain names consistently for certain kinds of
- values. Some of the commonest and least obvious are these two:
- <h4><a name="code"></a><b><tt>code</tt></b></h4>
- <blockquote>
- A value to be returned from a procedure:
- <table cellpadding=0 cellspacing=0>
- <tr valign=top> <td align=right>< 0
- <td>
- <td>An error code defined in
- <a href="../src/gserrors.h">gserrors.h</a>
- (or <a href="../src/ierrors.h">ierrors.h</a>)
- <tr valign=top> <td align=right>0
- <td>
- <td>Normal return
- <tr valign=top> <td align=right>> 0
- <td>
- <td>A non-standard but successful return (which must be documented, preferably with the procedure's prototype)
- </table>
- </blockquote>
- <h4><a name="status"></a><b><tt>status</tt></b></h4>
- <blockquote>
- A value returned from a stream procedure:
- <table cellpadding=0 cellspacing=0>
- <tr valign=top> <td align=right>< 0
- <td>
- <td>An exceptional condition as defined in
- <a href="../src/scommon.h">scommon.h</a>
- <tr valign=top> <td align=right>0
- <td>
- <td>Normal return (or, from the "<b><tt>process</tt></b>" procedure, means that more input is needed)
- <tr valign=top> <td align=right>1
- <td>
- <td>More output space is needed (from the "<b><tt>process</tt></b>" procedure)
- </table>
- </blockquote>
- <h3><a name="Structure_type_descriptors"></a>Structure type descriptors</h3>
- <p>
- The Ghostscript memory manager requires run-time type information for every
- structure. (We don't document this in detail here: see the <a
- href="Develop.htm#Structure_descriptors">Structure descriptors</a> section
- of the developer documentation for details.) Putting the descriptor for a
- structure next to the structure definition will help keep the two
- consistent, so immediately after the definition of a structure
- <b><tt>xxx_s</tt></b>, define its structure descriptor:
- <blockquote>
- <b><tt>struct xxx_s {</tt></b><br>
- ... members ...<br>
- <b><tt>};</tt></b><br>
- <b><tt>#define private_st_xxx() /* in </tt></b><filename><tt><b>.c */\</tt></b><br>
- <b><tt> gs_private_st_</tt></b><whatever><b><tt>(st_xxx, xxx_t,\</tt></b><br>
- <b><tt> "xxx_t", xxx_enum_ptrs, xxx_reloc_ptrs,\</tt></b><br>
- <b><tt> </tt></b>... additional parameters as needed ...<b><tt>)</tt></b>
- </blockquote>
- <p>
- The file that implements operations on this structure
- (<filename><b><tt>.c</tt></b>) should then include, near the
- beginning, the line:
- <blockquote>
- <b><tt>private_st_xxx();</tt></b>
- </blockquote>
- <p>
- In much existing code, structure descriptors are declared as
- <b><tt>public</tt></b>, which allows clients to allocate instances of the
- structure directly. We now consider this bad design. Instead, structure
- descriptors should always be <b><tt>private</tt></b>; the implementation
- file should provide one or more procedures for allocating instances, e.g.,
- <blockquote>
- <b><tt>xxx_t *gs_xxx_alloc(P1(gs_memory_t *mem));</tt></b>
- </blockquote>
- <p>
- If it is necessary to make a structure descriptor public, it should be
- declared in its clients as
- <blockquote>
- <b><tt>extern_st(st_xxx);</tt></b>
- </blockquote>
- <h3><a name="Objects"></a>"Objects"</h3>
- <p>
- Ghostscript makes heavy use of object-oriented constructs, including
- analogues of classes, instances, subclassing, and class-associated
- procedures. However, these constructs are implemented in C rather than C++,
- for two reasons:
- <ul>
- <li>The first Ghostscript code was written in 1986, long before C++ was
- codified or was well supported by tools. Even today, C++ tools rarely
- support C++ as well as C tools support C.
- <li>C++ imposes its own implementations for virtual procedures, inheritance,
- run-time type information, and (to some extent) memory management.
- Ghostscript requires use of its own memory manager, and also sometimes
- requires the ability to change the virtual procedures of an object
- dynamically.
- </ul>
- <h4>Classes</h4>
- <p>
- The source code representation of a class is simply a
- <b><tt>typedef</tt></b> for a C <b><tt>struct</tt></b>. See <a
- href="C-style.htm#Structures">Structures</a>, above, for details.
- <h4>Procedures</h4>
- <p>
- Ghostscript has no special construct for non-virtual procedures associated
- with a class. In some cases, the <b><tt>typedef</tt></b> for the class is
- in a header file but the <b><tt>struct</tt></b> declaration is in the
- implementation code file: this provides an extra level of opaqueness, since
- clients then can't see the representation and must make all accesses through
- procedures. You should use this approach in new code, if it doesn't
- increase the size of the code too much or require procedure calls for very
- heavily used accesses.
- <p>
- Ghostscript uses three different approaches for storing and accessing
- virtual procedures, plus a fourth one that is recommended but not currently
- used. For exposition, we assume the class (type) is named
- <b><tt>xxx_t</tt></b>, it has a virtual procedure
- <b><tt>void (*virtu)(P1(xxx_t *))</tt></b>, and we have a variable
- declared as <b><tt>xxx_t *pxx</tt></b>.
- <ol>
- <li>The procedures are stored in a separate, constant structure of type
- <b><tt>xxx_procs</tt></b>, of which <b><tt>virtu</tt></b> is a member. The
- structure definition of <b><tt>xxx_t</tt></b> includes a member defined as
- <b><tt>const xxx_procs *procs</tt></b> (always named
- <b><tt>procs</tt></b>). The construct for calling the virtual procedure is
- <b><tt>pxx->procs->virtu(pxx)</tt></b>.
- <li>The procedures are defined in a structure of type
- <b><tt>xxx_procs</tt></b> as above. The structure definition of
- <b><tt>xxx_t</tt></b> includes a member defined as
- <b><tt>xxx_procs procs</tt></b> (always named <b><tt>procs</tt></b>).
- The construct for calling the virtual procedure is
- <b><tt>pxx->procs.virtu(pxx)</tt></b>.
- <li>The procedures are not defined in a separate structure: each procedure
- is a separate member of <b><tt>xxx_t</tt></b>. The construct for calling
- the virtual procedure is <b><tt>pxx->virtu(pxx)</tt></b>.
- <li>The procedures are defined in a structure of type
- <b><tt>xxx_procs</tt></b> as above. The structure definition of
- <b><tt>xxx_t</tt></b> includes a member defined as
- <b><tt>xxx_procs procs[1]</tt></b> (always named
- <b><tt>procs</tt></b>). The construct for calling the virtual procedure is
- again <b><tt>pxx->procs->virtu(pxx)</tt></b>.
- </ol>
- <p>
- Note that in approach 1, the procedures are in a shared constant structure;
- in approaches 2 - 4, they are in a per-instance structure that can be
- changed dynamically, which is sometimes important.
- <p>
- In the present Ghostscript code, approach 1 is most common, followed by 2
- and 3; 4 is not used at all. For new code, you should use 1 or 4: that way,
- all virtual procedure calls have the same form, regardless of whether the
- procedures are shared and constant or per-instance and mutable.
- <h4>Subclassing</h4>
- <p>
- Ghostscript's class mechanism allows for subclasses that can add data
- members, or can add procedure members if approach 1 or 3 (above) is used.
- Since C doesn't support subclassing, we use a convention to accomplish it.
- In the example below, <b><tt>gx_device</tt></b> is the root class; it has a
- subclass <b><tt>gx_device_forward</tt></b>, which in turn has a subclass
- <b><tt>gx_device_null</tt></b>. First we define a macro for all the members
- of the root class, and the root class type. (As for structures in general,
- classes need a structure descriptor, as discussed in <a
- href="#Structures">Structures</a> above: we include these in the examples
- below.)
- <blockquote><b><tt>
- #define gx_device_common\<br>
- type1 member1;\<br>
- </tt></b>...<b><tt><br>
- typeN memberN<br>
- <br>
- typedef struct gx_device_s {<br>
- gx_device_common;<br>
- } gx_device;<br>
- <br>
- #define private_st_gx_device() /* in gsdevice.c */\<br>
- gs_private_st_</tt></b><whatever><b><tt>(st_gx_device, gx_device,\<br>
- "gx_device", device_enum_ptrs, device_reloc_ptrs,\<br>
- </tt></b>... additional parameters as needed ...<b><tt>)</tt></b>
- </tt></b></blockquote>
- <p>
- We then define a similar macro and type for the subclass.
- <blockquote><b><tt>
- #define gx_device_forward_common\<br>
- gx_device_common;\<br>
- gx_device *target<br>
- <br>
- typedef struct gx_device_forward_s {<br>
- gx_device_forward_common;<br>
- } gx_device_forward;<br>
- <br>
- #define private_st_device_forward() /* in gsdevice.c */\<br>
- gs_private_st_suffix_add1(st_device_forward, gx_device_forward,\<br>
- "gx_device_forward", device_forward_enum_ptrs, device_forward_reloc_ptrs,\<br>
- gx_device, target)
- </tt></b></blockquote>
- <p>
- Finally, we define a leaf class, which doesn't need a macro because we don't
- currently subclass it. (We can create the macro later if needed, with no
- changes anywhere else.) In this particular case, the leaf class has no
- additional data members, but it could have some.
- <blockquote><b><tt>
- typedef struct gx_device_null_s {<br>
- gx_device_forward_common;<br>
- };<br>
- <br>
- #define private_st_device_null() /* in gsdevice.c */\<br>
- gs_private_st_suffix_add0_local(st_device_null, gx_device_null,\<br>
- "gx_device_null", device_null_enum_ptrs, device_null_reloc_ptrs,\<br>
- gx_device_forward)
- </tt></b></blockquote>
- <p>
- Note that the above example is <strong>not</strong> the actual definition of
- the <b><tt>gx_device</tt></b> structure type: the actual type has some
- additional complications because it has a finalization procedure. See <a
- href="../src/gxdevcli.h">src/gxdevcli.h</a> for the details.
- <p>
- If you add members to a root class (such as <b><tt>gx_device</tt></b> in
- this example), or change existing members, do this in the
- <b><tt>gx_device_common</tt></b> macro, not the <b><tt>gx_device</tt></b>
- structure definition. Similarly, to change the
- <b><tt>gx_device_forward</tt></b> class, modify the
- <b><tt>gx_device_forward_common</tt></b> macro, not the structure
- definition. Only change the structure definition if the class is a leaf
- class (one with no <b><tt>_common</tt></b> macro and no possibility of
- subclassing), like <b><tt>gx_device_null</tt></b>.
- <h3><a name="Error_handling"></a>Error handling</h3>
- <p>
- Every caller should check for error returns and, in general, propagate them
- to <b>its</b> callers. By convention, nearly every procedure returns an
- <b><tt>int</tt></b> to indicate the outcome of the call:
- <blockquote><table cellpadding=0 cellspacing=0>
- <tr valign=top> <td align=right>< 0
- <td>
- <td>Error return
- <tr valign=top> <td align=right>0
- <td>
- <td>Normal return
- <tr valign=top> <td align=right>> 0
- <td>
- <td>Non-error return other than the normal case
- </table></blockquote>
- <p>
- To make a procedure generate an error and return it, as opposed to
- propagating an error generated by a lower procedure, you should use
- <blockquote>
- <b><tt>return_error(</tt></b><em>error_number</em><b><tt>);</tt></b>
- </blockquote>
- <p>
- Sometimes it is more convenient to generate the error in one place and
- return it in another. In this case, you should use
- <blockquote>
- <b><tt>code = gs_note_error(</tt></b><em>error_number</em><b><tt>);</tt></b><br>
- ...<br>
- <b><tt>return code;</tt></b>
- </blockquote>
- <p>
- In executables built for debugging, the <b><tt>-E</tt></b> (or
- <b><tt>-Z#</tt></b>) command line switch causes <b><tt>return_error</tt></b>
- and <b><tt>gs_note_error</tt></b> to print the error number and the source
- file and line: this is often helpful for identifying the original cause of
- an error.
- <p>
- See the file <a href="../src/gserrors.h">src/gserrors.h</a> for the error
- return codes used by the graphics library, most of which correspond directly
- to PostScript error conditions.
- <!-- [2.0 end contents] ==================================================== -->
- <!-- [3.0 begin visible trailer] =========================================== -->
- <hr>
- <p>
- <small>Copyright © 1996, 1997, 1998 Aladdin Enterprises.
- Copyright © 2001 artofcode LLC.
- All rights reserved.</small>
- <p>
- <small>This file is part of AFPL Ghostscript. See the <a
- href="Public.htm">Aladdin Free Public License</a> (the "License") for full
- details of the terms of using, copying, modifying, and redistributing AFPL
- Ghostscript.</small>
- <p>
- <small>Ghostscript version 8.53, 20 October 2005
- <!-- [3.0 end visible trailer] ============================================= -->
- </body>
- </html>
|