Portable custom integer width definitions

Discussion in 'C Programming' started by James Harris, Jul 9, 2013.

  1. Such compilers could be very near that boundary, and are clearly on the
    far side of it.
    Keith Thompson, Jul 10, 2013
    1. Advertisements

  2. Another common feature is that they don't allow recursion. The example I
    used did have a type it called double. But it implemented it with a one byte
    exponent and an two byte mantissa.

    But it was still C. If you knew C you could pick up on its little quirks
    very quickly.
    Malcolm McLean, Jul 10, 2013
    1. Advertisements

  3. Malcolm:

    How long have you been reading and posting to this group?

    Surely, you know by now that, in the religion of this group, anything that
    is not 100.000% compliant with the standard, then it is "not C" (A phrase
    which, if pronounced quickly, describes well the political leanings of many
    of the posters in this group) - and might as well be called any or all of
    the following:

    a) baseball
    b) Pascal
    c) Your ear

    All are acceptable terms to describe this abomination - this thing you talk
    about has (God forbid!) 8 bit ints.

    Modern Conservative: Someone who can take time out
    from demanding more flag burning laws, more abortion
    laws, more drug laws, more obscenity laws, and more
    police authority to make warrantless arrests to remind
    us that we need to "get the government off our backs".
    Kenny McCormack, Jul 10, 2013
  4. I suppose it depends on how you define "C".

    Conveniently, we have a definition that most implementers and users
    agree on, namely the standard.

    What you're describing is an implementation of a very C-like language;
    you could also call it a dialect. And there's nothing wrong with
    implementing or using such a language; it could be very useful for its
    problem domain.

    But if I write a C program that assumes int is at least 16 bits,
    or that functions can be recursive, and it doesn't work, then
    either it's the implementation's fault for failing to compile a
    valid program, or it's my fault for using something that's not a C
    compiler for my C code. C++ and C-- (yes, there is a C-- language)
    are both C-like languages; neither of them is C.

    The question is where you draw the line between C and non-C. I know
    where I draw it.
    Keith Thompson, Jul 10, 2013
  5. James Harris

    James Harris Guest

    On Tuesday, July 9, 2013 5:01:55 PM UTC+1, Eric Sosman wrote:

    Well, I'll consider myself suitably admonished. :) Yes, a user of a language *should* learn its rules but I would say that for an occasional user there seem to be lots of them to learn. Fine if you are using C every day; forintermittent use it is tempting to stick to the parts one is familiar with..

    C is arguably no longer one language as it was in the early days, and the new versions are far from simple to judge by the many discussions about detailed differences that I have seen.

    Some folk here won't like my next comment (asbestos drawers on...) but it is intended to express a viewpoint: Ritchie's C used to be (or at least appear to be) an admirably straightforward language but for a number of reasonshas become a set of similar languages with highly complex rules about details - a domain for language lawyers, if you like. That's not meant to be a criticism of anyone, just a comment on how the versions of C can seem to anoccasional user.

    In fact I do use C fairly often but tend to stick to what I know or what the compiler I have available will accept. Compilers don't always implement standard C and hence add to the potential confusion. Maybe I should ask about compiler recommendations but that would be another thread.

    That said, I should learn more of C (and of the preprocessor which is really the point of discussion above). What text(s) would you recommend? I tend to use Google or a FAQ site I found in order to find answers to specific questions as they arise but could do with some more systematic approach especially if I am going to make heavier use of it.

    This is a great case in point: folks here seemed to know that <limits.h> would be available and it was on both compilers, even the old 16-bit one. Does that knowledge come from experience of dealing with similar issues or from specific documentation? If the latter, which documents?

    James Harris, Jul 10, 2013
  6. James Harris

    James Harris Guest

    Yes, something like this might help. I'm not a fan of big lists of defines especially if a number of them need to be updated at a time. If I did do something like that it might be based on the log2 of the architecture width so that later values adapted automatically to one key change.

    There are also things that a big set of defines might not cope well with soI'm not yet settled on any one solution. I'm just looking for ideas at themoment (and comments here have been a big help).

    BTW, it's funny to think of adapting C to what assembly code wants. ISTM a far bigger issue to do all the assembler work to adapt to what the compilers need! IME compilers might be code generators but they don't do much to generate code to any other standards than the ones they use internally. Anyone who wants to work with a compiler has to dance to that compiler's tune.

    James Harris, Jul 10, 2013
  7. James Harris

    James Harris Guest

    A good question if the answer is simple. In this case it would take some screeds of text to explain the whole story and, to coin a phrase, would be OT for this newsgroup. And, no, it's nothing as simple as "int x int". :)

    James Harris, Jul 10, 2013
  8. James Harris

    James Harris Guest

    Thanks. I took a good look at it. It seems to set its fundamental data based on recognition of specific compiler predefines (which doesn't seem too rigorous). That said, it looks like a good source of definitions once the basic values are set.

    James Harris, Jul 10, 2013
  9. James Harris

    James Kuyper Guest

    C is a little too complicated a language for intermittent use. A
    higher-level language that protects you from some of the details might
    be a better idea.
    The C standard left many things implementation-defined and undefined,
    and therefore allows considerable variation in how the language is
    implemented. However, this variation was only formalized by C90, it was
    not created by it. K&R allowed a wider range of variations than C90 did,
    and was far less clear about what variations were allowed. Since it
    wasn't a standard, implementors didn't feel constrained to follow K&R
    precisely - they frequently treated it more as a source of inspiration,
    rather than as a precise specification of how the language works.

    The new standard was, in itself, yet another new version of C, and more
    different from many existing implementations than they were from each
    other. However, it was rapidly and widely adopted by many people who
    were sick and tired of the hassle of dealing with the many different
    variations on K&R C. As a result, the long term effect was actually a
    substantial reduction in the variety of different implementations.

    Now, C99 never succeeded in fully replacing C90, so it increased the
    diversity of C. C2011 will probably have the same effect, for much the
    same reasons. On top of that, C2011 officially made several features
    optional, which means that we now have small family of different
    standard versions of C. Still, I can't help wondering if your feeling
    that C was far more united in "the early days" has more to due with
    nostalgia than with reality. What specific things give you the feeling
    that C is more diverse now?
    The complex rules about details replaced, for the most part,
    corresponding ambiguities in the K&R specification. In the days before
    the standard, a portability guru had to be familiar with all the
    different ways different real-world implementations interpreted (or
    mis-interpreted or extended) what K&R said. Nowadays, a portability guru
    has the much simpler task of being familiar with all the different
    variations allowed by the words of the standard. It seems more
    complicated, but only because the details are fully specified; the
    actual variety of possibilities that need to be considered is much smaller.
    Almost every compiler made in the last decade has a mode that is nearly,
    if not fully, conforming to either C90 or C99, and many have both modes.

    That's such basic information that I no longer remember the
    circumstances under which I first learned about it; it probably happened
    at least 20 years ago. The place I would go to now, to get information
    about similar things (such as the new headers provided by C2011) would
    be the latest free draft version of the C2011 standard:
    <http://open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf>. It's nearly as
    good, for almost all purposes, as the official standard, and it's a lot
    cheaper. Each section from 7.2 to 7.30 corresponds to one of the
    standard headers. 7.10 describes <limits.h>.
    James Kuyper, Jul 10, 2013
  10. James Harris

    Eric Sosman Guest

    If you have "big lists" of different types you're handing
    back and forth between C and assembly, you're already in a world
    of hurt.

    How many different flavors of integer do you *really* need
    to volley across the interlingual tennis net? You can use as many
    as you like on each side, but you'll save yourself a lot of grief
    by keeping the interface narrow.

    "Simplify, simplify." -- HDT, "Walden" Chapter 2

    "Simplicity, simplicity, simplicity!" -- Ibid
    Right. The benefit is that you don't need to learn how to
    play the tune on the glockenspiel, the tuba, the violoncello,
    the flugelhorn, the marimbas, the oboe (that's "an ill woodwind
    nobody blows good"), AND the left-handed sewer flute. Learn the
    tune, learn the steps, let the local band make the music, and
    enjoy the dance.
    Eric Sosman, Jul 10, 2013
  11. James Harris

    Eric Sosman Guest

    It appears you're building a program that links C with other
    languages. That's not a target a casual drive-by shooter will hit
    with high probability ...
    C today is more languages than in the very early days, but fewer
    than in the middle ages. *Vastly* fewer. Trust me: I was there.
    Um, er, "It'd be a good idea to acquaint yourself with the
    rules of the language you're using."
    Eric Sosman, Jul 10, 2013
  12. James Harris

    James Harris Guest

    On Wednesday, July 10, 2013 9:58:37 PM UTC+1, James Kuyper wrote:


    BTW, based on your comments and on Wikipedia I make it that there are theseprincipal versions:

    K&R --> many implementations --> C89 (aka C90) --> C99 --> C11

    where C11 is yet to be ratified.
    If you are asking about my comment above I think it was less about diversity than it was about the versions of C being far from simple. I meant that despite the ostensible simplicity of the language there are lots of details for programmers to remember. In part these are related to the things that go along with the language: preprocessor and standard library.

    That said, I have been rereading K&R2 and there are lots of detailed rules in there that I had forgotten so even the old version has it complexities.

    Thanks. Have taken a copy.

    James Harris, Jul 11, 2013
  13. James Harris

    Eric Sosman Guest

    I guess you're working on software for a time machine, and
    the beta version is already able to travel back almost two years.
    ("The [C11] standard [...] was officially ratified by ISO [...]
    on December 8, 2011 [...]" -- Wikipedia)
    Eric Sosman, Jul 11, 2013
  14. James Harris

    James Harris Guest

    Yes, I'll try to keep the interfacing complexity low.


    And when the asm code is given a new partner to dance with it finds it is expected to carry out the same dance but with different steps!

    James Harris, Jul 11, 2013
  15. James Harris

    James Harris Guest

    On the contrary, the Delorean was working so well two years ago it has just reappeared!

    James Harris, Jul 11, 2013
  16. The C11 standard was released by ISO in December 2011. Officially (as
    far as ISO, ANSI, and other national bodies are concerned), C11 cancels
    and replaces the C99 standard, which cancelled and replaced the C90
    standard. (In practice, the older standards are still in use, and as
    far as I know no implementation has fully implemented the current


    Note that K&R2 is based on the C89/C90 standard.
    You might also be interested in
    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, which is a
    draft of the C99 standard. It incorporates the full C99 standard plus
    all three Technical Corrigenda, and thus is a more accurate reflection
    of the pre-C11 language definition than the standard itself.
    Keith Thompson, Jul 11, 2013
  17. James Harris

    BartC Guest

    Yes, C is *deceptively* simple; it's not! It wouldn't be so bad if it was
    just the base language, but a typical C project will consist of:

    * The C code itself (as you've discovered, now carrying a huge amount of

    * The type-declaration syntax (part of C, but I like to think of it as a
    separate beast)

    * Sets of macros using the language of the preprocessor

    * The set of compiler options (gcc has 1200 of these) and assorted
    incantations essential to compiling the source code. These will necessarily
    involve a specific compiler and version.

    * Make files with precise, specific instructions to build a project (which
    are completely mystery to me, and which I have *never* known to
    work properly!). As I understand it, the language of a make file is tied to
    a particular Make utility.

    So in reality four or five different 'languages'. The macro language in
    particular is an excellent obfustication tool.
    BartC, Jul 11, 2013
  18. There's only a handful of Make variants out there, and the UNIX/GNU ones
    all use pretty much the same language; developers on other platforms
    seem to prefer other tools these days, e.g. GUI IDEs.

    I've read hundreds of Makefiles over the years, and they don't seem
    mysterious aside from the voodoo for auto-updating dependencies. I've
    also never had one in an open-source package fail to work properly
    except when (unwisely) trying to mix recursive Makefiles* with parallel

    Autoconf and Automake, though, are horrific beasts; the results border
    on magical when the scripts are crafted by experts, but I've never
    managed to get even trivial projects working from scratch.



    * http://aegis.sourceforge.net/auug97.pdf
    Stephen Sprunk, Jul 11, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.