Re: Unicode & space in programming & l10n

From: Steve Summit (
Date: Fri Sep 22 2006 - 19:44:55 CDT

  • Next message: John D. Burger: "Re: Unicode & space in programming & l10n"

    I wrote:
    >>> Please don't do this! Please do
    >>> #include <stdint.h>
    >>> instead.

    And almost immediately Ken Whistler and Richard Wordingham replied:

    >> Well, sure, *if* your compilers are all completely up-to-date.


    > It will only work if your compiler acknowledges the C99 standard.
    > The ones I use don't claim to comply, and the one I use at home would
    > simply fail to compile the above.

    On the one hand, not all the compilers I use are C99-compatible,
    either. But on the other hand, C99 has been out for *seven
    years* now, so presuming its features is not completely out of
    the question. (And in the case at hand, the <inttypes.h> header
    had been in circulation even before C99 came out.)

    But in this case, even if your compilers aren't all
    C99-compatible, its prescriptions provide a very clear
    implementation path. First, begin weeding out all your ad-hoc
    project-specific int16 and Uint32 typedef names, and standardize
    on uint16_t and uint32_t et al.

    Next, if at all possible, move the question of <stdint.h>'s
    presence out of your source code and into your build procedure.
    What I always do for pre-ANSI compilers lacking ANSI-standard
    headers is to provide my own copies of the standard headers
    (not necessarily wholly complete, but providing the definitions
    my code depends on), and to cause the compiler to additionally
    search for my headers in addition to the standard ones, using
    a compiler switch such as -I or the like. This ends up being
    compiler-specific and a bit of a nuisance, it's true, but it's no
    more compiler-specific or nuisancey than explicit #ifdefs in the
    source code would be, and by doing it this way, you can confine
    the compiler dependencies to the build procedure (which is always
    going to be compiler-dependent anyway), leaving all the source
    code pristine.

    This archive was generated by hypermail 2.1.5 : Fri Sep 22 2006 - 19:47:13 CDT