Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Suitable type names needed for portable integers

Reply
Thread Tools

Suitable type names needed for portable integers

 
 
Keith Thompson
Guest
Posts: n/a
 
      08-16-2013
David Brown <(E-Mail Removed)> writes:
[...]
> If you drop the 16-bit x86 support, then all your compilers will have
> C99 at least. It is not unreasonable to expect support of a 15 year old
> standard as a minimum. And even most pre-C99 compilers have stdint.h
> You should therefore use <stdint.h>, and follow standard practice,
> rather than re-inventing your own little wheel.


Microsoft's C compiler does not support C99. As of VS2010, it does
support <stdint.h> as an extension, but I wouldn't count on it in
general for non-C99 compilers.

If you need to support systems without <stdint.h>, it isn't that
complicated. At least for the types defined there (which doesn't
include all the types you want), my advice is this: Don't reinvent your
own wheel. Reinvent <stdint.h>.

For example, you can write your own header "my_stdint.h", something
like:

#ifndef H_MY_STDINT
#define H_MY STDINT
#if __STDC_VERSION__ >= 199901L
#include <stdint.h>
#else
typedef uint8_t ...
typedef int8_t ...
/* etc. */
#endif
#endif

Then your code can use `#include "my_stdint.h"` rather than `#include
<stdint.h>`.

Tweak the `#if` if you want to use <stdint.h> on non-C99 compilers that
support it as an extension.

Writing the "/* etc */" is left as an exercise, but one that's already
been done numerous times, including this: <http://www.lysator.liu.se/c/q8/>.

[snip]

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      08-16-2013
On 08/16/2013 12:03 PM, Keith Thompson wrote:
> "BartC" <(E-Mail Removed)> writes:
> [...]

....
>> Actually I think you can override built-in names too for that
>> matter:
>>
>> #define int int32_t
>>
>> But use with some care...

>
> I believe macros that redefine keywords cause undefined behavior.


That is often the case, but it is possible to redefine a keyword with
defined behavior.

"The above tokens (case sensitive) are reserved (in translation phases 7
and for use as keywords, and shall not be used otherwise." 6.4.1p2.
Note that the reservation does not apply until phase 7.

"The program shall not have any macros with names lexically identical to
keywords currently defined prior to the inclusion of the header or when
any macro defined in the header is expanded." (7.1.2p4)

If you #define a keyword, and then #undef it if necessary before the
next #include of a standard header, or the next use of something that
might be a macro defined in a standard header, the behavior is
well-defined (assuming there's no other problem). I wouldn't recommend
it though.

Given that any standard library function might be a function-like macro,
it's hard to imagine how BartC's suggested #define could be useful if
used only in accord with those restrictions.

> They're certainly dangerous. For example, if `int32_t` is a typedef,
> then the above macro definition makes `unsigned int` a syntax error.
>
> Don't do that.


Agreed.


 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      08-16-2013
Nick Bowler <(E-Mail Removed)> writes:
> On Fri, 16 Aug 2013 09:03:14 -0700, Keith Thompson wrote:
>
>> "BartC" <(E-Mail Removed)> writes:

> [...]
>>> Actually I think you can override built-in names too for that matter:
>>>
>>> #define int int32_t
>>>
>>> But use with some care...

>>
>> I believe macros that redefine keywords cause undefined behavior.
>> They're certainly dangerous. For example, if `int32_t` is a typedef,
>> then the above macro definition makes `unsigned int` a syntax error.

>
> It's only undefined behaviour if such macros are defined before
> including a standard header, or if such macros are defined before
> expanding a macro defined in a standard header.


You're right. C11 7.1.2p4.

> Still doesn't make it a good idea, though.


Agreed. It's difficult to avoid expanding a macro defined in a standard
header; most standard library functions can be defined as macros.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ian Pilcher
Guest
Posts: n/a
 
      08-16-2013
How about [u]int_word_t for the type that always matches the word size
of the processor?

The 16/32/32 case is tougher, but maybe something like [u]int_word32_t
to indicate that it matches the word size up to 32 bits? This has the
advantage of giving you a naming convention for your 16/32/64/64 type
when you port your OS to a 128-bit architecture.

--
================================================== ======================
Ian Pilcher (E-Mail Removed)
Sometimes there's nothing left to do but crash and burn...or die trying.
================================================== ======================
 
Reply With Quote
 
James Harris
Guest
Posts: n/a
 
      08-16-2013
"Ian Pilcher" <(E-Mail Removed)> wrote in message
news:TduPt.93420$(E-Mail Removed)...
> How about [u]int_word_t for the type that always matches the word size
> of the processor?
>
> The 16/32/32 case is tougher, but maybe something like [u]int_word32_t
> to indicate that it matches the word size up to 32 bits? This has the
> advantage of giving you a naming convention for your 16/32/64/64 type
> when you port your OS to a 128-bit architecture.


LOL - yes, it pays to plan ahead!

How would uint_word and uint_short look to you? Or for closer matching to
other names I already have defined, ui_word and ui_short?

By the way, what's the standard deal with the _t? I see it sometimes used on
type names and sometimes not.

James


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-17-2013
"James Harris" <(E-Mail Removed)> writes:
> "Ian Pilcher" <(E-Mail Removed)> wrote in message
> news:TduPt.93420$(E-Mail Removed)...
>> How about [u]int_word_t for the type that always matches the word size
>> of the processor?
>>
>> The 16/32/32 case is tougher, but maybe something like [u]int_word32_t
>> to indicate that it matches the word size up to 32 bits? This has the
>> advantage of giving you a naming convention for your 16/32/64/64 type
>> when you port your OS to a 128-bit architecture.

>
> LOL - yes, it pays to plan ahead!
>
> How would uint_word and uint_short look to you? Or for closer matching to
> other names I already have defined, ui_word and ui_short?
>
> By the way, what's the standard deal with the _t? I see it sometimes used on
> type names and sometimes not.


As far as the C standard is concerned, there's nothing special about a
_t suffix. It means "type", but there's no particular consistency about
its use.

I think POSIX reserves identifiers ending with _t.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Harris
Guest
Posts: n/a
 
      08-17-2013
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "James Harris" <(E-Mail Removed)> writes:


....

>> By the way, what's the standard deal with the _t? I see it sometimes used
>> on
>> type names and sometimes not.

>
> As far as the C standard is concerned, there's nothing special about a
> _t suffix. It means "type", but there's no particular consistency about
> its use.
>
> I think POSIX reserves identifiers ending with _t.


Ah. Does that mean we should not use _t suffix on our type names?

AIUI names such as stripe, town, memo and isomer are reserved from being
externs. If so there's too much reserving of names going on!
James


 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-17-2013
On 08/17/2013 03:13 AM, James Harris wrote:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...

....
>> As far as the C standard is concerned, there's nothing special about a
>> _t suffix. It means "type", but there's no particular consistency about
>> its use.
>>
>> I think POSIX reserves identifiers ending with _t.

>
> Ah. Does that mean we should not use _t suffix on our type names?


The type names ending with _t have file scope, and belong to the name
space for ordinary identifiers. The corresponding POSIX reservation
applies only at file scope, so you can use _t as a type name if it has
any other scope. However, the POSIX reservation includes all identifiers
in the ordinary name space - that includes variable names, function
names, and enumeration constants. You can freely use names ending in _t
as label names, and as tags or member names for structures, union, or
enumerations.
--
James Kuyper
 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      08-19-2013
In article <(E-Mail Removed)>,
James Kuyper <(E-Mail Removed)> wrote:
>
>The <stdint.h> header that was added in C99 provides three pairs of
>families of type names: [u]intN_t, [u]int_leastN_t, and [u]int_fastN_t.


Yes, I'm a little confused actually. <stdint.h> is the obvious choice,
and I'm wondering why OP isn't just using it.

--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-19-2013
On 08/19/2013 04:44 PM, Edward A. Falk wrote:
> In article <(E-Mail Removed)>,
> James Kuyper <(E-Mail Removed)> wrote:
>>
>> The <stdint.h> header that was added in C99 provides three pairs of
>> families of type names: [u]intN_t, [u]int_leastN_t, and [u]int_fastN_t.

>
> Yes, I'm a little confused actually. <stdint.h> is the obvious choice,
> and I'm wondering why OP isn't just using it.


His target systems include ones where C99 is not supported. Of course,
many of those systems support <stdint.h>, or some variant thereof, as a
C90 extension. Even on the ones that don't, it would be feasible to
provide your own, and there exist well-know versions in the public
domain. However, these points have been made to him, and don't seem to
have affected his thinking.

The fundamental problem, I think, is that he doesn't trust the C
compiler or <stdint.h> to have made what he considers to be the correct
choice. Using C necessarily involves giving up a certain amount of
control over the generated code, compared to assembly language. That's
part of what makes it a higher-level language. It's very low-level for a
high-level language, but it is still, definitely, a high-level language,
at least by comparison with assembler.

I've seen such attitudes before, both in people moving to C from
assembler, and in C programmers who are temperamentally better suited to
being assembly language programmers than C programmers. The first group
needs to learn to let go and let C do its thing. The second group needs
to switch to some other language better suited to their temperaments.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reference type for C roland.arthaud@gmail.com C Programming 206 05-28-2013 01:53 AM
Suitable libraries for implementing a "push"-type matching engine? Andrew Warkentin Python 0 04-11-2008 09:23 AM
Portable Python - free portable development environment ! perica.zivkovic@gmail.com Python 7 01-13-2007 11:19 AM
portable (VHDL) vs. non-portable (altera LPM) approaches to signed computations Eli Bendersky VHDL 1 03-01-2006 02:43 PM
XSL rules applying to XSD (XML schema) defined type names (as opposed to node names) Lewis G. Pringle, Jr. XML 0 09-30-2003 10:34 PM



Advertisments