Portable custom integer width definitions

K

Keith Thompson

Malcolm McLean said:
I'd disagree. A language can be nearly conforming, and still what anyone
would call C. Obviously as it gets steadily further from standard C
and from K and R C, the issue will arise, "is it still really C or is
it now effectively another language?". But compilers for tiny embedded
system that think it's more important that int fit in a register than
that it hold values of up 32767 aren't anywhere near that boundary.

Such compilers could be very near that boundary, and are clearly on the
far side of it.
 
M

Malcolm McLean

Such compilers could be very near that boundary, and are clearly on the
far side of it.
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.
 
K

Kenny McCormack

Malcolm McLean said:
I'd disagree. A language can be nearly conforming, and still what anyone
would call C. Obviously as it gets steadily further from standard C
and from K and R C, the issue will arise, "is it still really C or is
it now effectively another language?". But compilers for tiny embedded
system that think it's more important that int fit in a register than
that it hold values of up 32767 aren't anywhere near that boundary.

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".
 
K

Keith Thompson

Malcolm McLean said:
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.

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.
 
J

James Harris

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

....
If you're striving for portability, it'd be a good idea to
acquaint yourself with the rules of the language you're using ...

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.

....
Various people have written <stdint.h> fill-ins for pre-C99
compilers, and you may be able to find one you can borrow. If not,
for what you need it's straightforward to cobble something together
using the values in <limits.h>, e.g.

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
 
J

James Harris

Surely if you're interfacing to assembler, a "types" #include specific
to each implementation is not unreasonable. The assembler will
already by specific to the implementation, what's one additional
header file so you can match what the assembler code wants?

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
 
J

James Harris

+1. The question "what are you really trying to do?" seems
appropriate. Some requirement hides behind the "I want an portable
integer exactly twice as wide as int" statement, but we can only guess
what it is. "int * int without overflow" was my guess, too.

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
 
J

James Harris

Doug Gwyn, a member of the ISO C standard committee, created some C99
(then C9x) porting supplements, including an implementation of
<stdint.h> for pre-C99 compilers. It's public domain, so you can use it
any way you like.

http://www.lysator.liu.se/c/q8/

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
 
J

James Kuyper

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; for intermittent use it is tempting to stick
to the parts one is familiar with.

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.
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.

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?
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 reasons has 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 an occasional user.

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.
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.

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.

....
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?

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>.
 
E

Eric Sosman

[...]
I will need some other integer types but in the context of the initial post in this thread they need to be exact widths as they will interface with assembly code.


Surely if you're interfacing to assembler, a "types" #include specific
to each implementation is not unreasonable. The assembler will
already by specific to the implementation, what's one additional
header file so you can match what the assembler code wants?

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.

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
There are also things that a big set of defines might not cope well with so I'm not yet settled on any one solution. I'm just looking for ideas at the moment (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.

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.
 
E

Eric Sosman

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; for intermittent use it is tempting to stick to the parts one is familiar with.

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 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.

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.
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?

Um, er, "It'd be a good idea to acquaint yourself with the
rules of the language you're using."
 
J

James Harris

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

....
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.

Understood.

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.
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?

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.

....
... 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>.

Thanks. Have taken a copy.

James
 
E

Eric Sosman

[...]
BTW, based on your comments and on Wikipedia I make it that there are these principal versions:

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

where C11 is yet to be ratified.

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)
 
J

James Harris

]
I will need some other integer types but in the context of the initial post in this thread they need to be exact widths as they will interface with assembly code.


Surely if you're interfacing to assembler, a "types" #include specific
to each implementation is not unreasonable. The assembler will
already by specific to the implementation, what's one additional
header file so you can match what the assembler code wants?

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.

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.

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

....
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.

:)

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
 
J

James Harris

[...]
BTW, based on your comments and on Wikipedia I make it that there are these principal versions:

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

where C11 is yet to be ratified.

I guess you're working on software for a time machine, and
the beta version is already able to travel back almost two years.

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

James
 
K

Keith Thompson

James Harris said:
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
these principal versions:

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

where C11 is yet to be ratified.

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
standard.)

[...]

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.

Note that K&R2 is based on the C89/C90 standard.
Thanks. Have taken a copy.

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.
 
B

BartC

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.

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
baggage)

* 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.
 
S

Stephen Sprunk

* 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.

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
building.

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.

YMMV.

S

* http://aegis.sourceforge.net/auug97.pdf
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,076
Messages
2,570,565
Members
47,200
Latest member
Vanessa98N

Latest Threads

Top