Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > On what does size of data types depend?

Reply
Thread Tools

On what does size of data types depend?

 
 
Keith Thompson
Guest
Posts: n/a
 
      10-07-2005
John Devereux <(E-Mail Removed)> writes:
> Jack Klein <(E-Mail Removed)> writes:
>> On 05 Oct 2005 14:14:03 +0100, John Devereux
>> <(E-Mail Removed)> wrote in comp.lang.c:
> >
>> > This brings to mind something that I have wondered about.
>> >
>> > I often see advice elsewhere, and in other peoples programs,
>> > suggesting hiding all C "fundamental" types behind typedefs such as
>> >
>> > typedef char CHAR;
>> > typedef int INT32;
>> > typedef unsigned int UINT32;

>>
>> The first one is useless, the second two are worse than useless, they
>> are dangerous, because on another machine int might have only 16 bits
>> and INT32 might need to be a signed long.

>
> Perhaps I was not clear; the typedefs go in a single "portability"
> header file and are specific to the machine. E.g.
>
> #ifdef __X86
> typedef short int INT16;
> ...
> #endif
> #ifdef __AVR
> typedef int INT16;
> ...
> #endif
>
> (made up examples)
>
> It should be understood that this file will need to be changed for
> each new machine, but that hopefully nothing else will. By using
> UINT32 etc thoughout, nothing needs to change except this one file.


Given that the definitions change for each platform (and assuming that
you always get it right), the INT16 and UIN32 typedefs are reasonable.
Since C99 defines similar typedefs in <stdint.h>, and since it also
distinguishes among exact-width, minimum-width, and fastest types,
you'd probably be better of using <stdint.h> if it's available, or
using a C90-compatible version of it if it's not (see
<http://www.lysator.liu.se/c/q8/>). (I can't connect to that site at
the moment.)

But the typedefs CHAR (for char) and PCHAR (for char*) are either
utterly useless or dangerously misleading. If you want type char, use
char; if you want a pointer to char, use char*. There's no point in
hiding these types behind typedefs that won't change from one platform
to another. And if they are going to change, they should be called
something other than CHAR and PCHAR.

> > typedef char* PCHAR;
>>
>> This is more dangerous yes, never typedef a pointer this way. At
>> least not if the pointer will ever be dereferenced using that alias.
>>
>> > The theory is that application code which always uses these typedefs
>> > will be more likely to run on multiple systems (provided the typedefs
>> > are changed of course).

>>
>> More than theory, very real fact.

>
> So that would make them a good thing? Sorry if I miss the point; you
> seem to be saying they are "worse than useless" but do improve
> portability?


I'm not sure what Jack Klein meant here, but I doubt that he meant
that CHAR and PCHAR are useful.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
 
Chris Torek
Guest
Posts: n/a
 
      10-07-2005
In article <(E-Mail Removed)>
Keith Thompson <(E-Mail Removed)> wrote:
>... But the typedefs CHAR (for char) and PCHAR (for char*) are either
>utterly useless or dangerously misleading. If you want type char, use
>char; if you want a pointer to char, use char*. There's no point in
>hiding these types behind typedefs that won't change from one platform
>to another. And if they are going to change, they should be called
>something other than CHAR and PCHAR.


Indeed. The whole point to "creating a type" (which typedef fails
to do, but that is another problem entirely) is to obtain abstraction:
"moving up a level" in a problem, making irrelevant detail go away
so that you work only with relevant detail. "Pointer to char" is
no more abstract than C's raw "char *": what irrelevant detail has
been removed?
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
 
 
 
Christian Bau
Guest
Posts: n/a
 
      10-08-2005
In article <(E-Mail Removed)>,
John Devereux <(E-Mail Removed)> wrote:

> I had to write a fairly simple windows program last week, and it was
> horrible. All those WORDS, DWORDS, LPCSTR, HPARAMS, LPARAMS etc. I
> think that experience was what prompted my post.


I can feel your pain. I don't mind things like UINT32; it seems to be
quite self-explanatory. I have a real problem with "WORD" and "DWORD"
which is used in Windows programs a lot: "WORD" is defined as a 16 bit
type and DWORD as a 32 bit type, which means that on your average
Pentium or Athlon processor a WORD is a halfword and a DWORD is a word,
whereas on a 64 bit processor a WORD is a quarterword and a DWORD is a
halfword - in other words, these typenames are complete nonsense.

And LPCSTR - "Long Pointer to C String". For heavens sake, what is a
"long pointer"?
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      10-08-2005
Christian Bau <(E-Mail Removed)> writes:

>I have a real problem with "WORD" and "DWORD"
> which is used in Windows programs a lot: "WORD" is defined as a 16 bit
> type and DWORD as a 32 bit type, which means that on your average
> Pentium or Athlon processor a WORD is a halfword and a DWORD is a word,
> whereas on a 64 bit processor a WORD is a quarterword and a DWORD is a
> halfword - in other words, these typenames are complete nonsense.
>
> And LPCSTR - "Long Pointer to C String". For heavens sake, what is a
> "long pointer"?


I suppose you do realize that these names refer to the types that
they do for historical reasons? That's not to say that they
aren't deceptive, but there was some sense behind them at the
time they were invented.
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield
 
Reply With Quote
 
Skarmander
Guest
Posts: n/a
 
      10-08-2005
Christian Bau wrote:
> In article <(E-Mail Removed)>,
> John Devereux <(E-Mail Removed)> wrote:
>
>
>>I had to write a fairly simple windows program last week, and it was
>>horrible. All those WORDS, DWORDS, LPCSTR, HPARAMS, LPARAMS etc. I
>>think that experience was what prompted my post.

>
>
> I can feel your pain. I don't mind things like UINT32; it seems to be
> quite self-explanatory. I have a real problem with "WORD" and "DWORD"
> which is used in Windows programs a lot: "WORD" is defined as a 16 bit
> type and DWORD as a 32 bit type, which means that on your average
> Pentium or Athlon processor a WORD is a halfword and a DWORD is a word,
> whereas on a 64 bit processor a WORD is a quarterword and a DWORD is a
> halfword - in other words, these typenames are complete nonsense.
>
> And LPCSTR - "Long Pointer to C String". For heavens sake, what is a
> "long pointer"?


No, LPCSTR is Hungarian abracadabra for "long pointer to *constant*
string". These days, it's the same thing as a regular pointer, and
"LPCSTR" is the same thing as "PCSTR", which, however, is almost never
used for hysterical reasons.

But back when Windows 3.0 roamed the earth, the 8086 segmented memory
model meant Windows too made the difference between "far" and "near"
pointers (calling them "long" and, well, nothing pointers for
consistency), depending on whether a pointer was constrained by the 64K
range of a segment or not.

The problem is that Microsoft tried to abstract away from actual data
types and mostly got it wrong; the abstraction wasn't and code that went
from 16 to 32 bits still broke happily -- though that wasn't Microsoft's
fault, they didn't help matters either.

They had an idea that might have been worthwhile, didn't stop to think
whether it was feasible and went on to implement it in a half-assed way,
yielding the current mess. You see, char* is typedef'ed to PCCHAR (yes,
"pointer to C char", not "constant char" -- const char* has no typedef),
to PSZ ("pointer to string that's zero-terminated", of course), then
char is typedef'ed to CHAR (huh?) and CHAR* is in turn typedef'ed to
PCHAR, LPCH, PCH, NPSTR, LPSTR and PSTR!

The semantic differences these are intended to convey is lost on the
vast majority of Windows programmers out there, and no small wonder too.
Of course the C compiler doesn't give a rat's ass about these fancy
typedefs, which means any "errors" in using them go undetected, except
by people who are fluent in this make-belief type system.

S.
 
Reply With Quote
 
Anonymous 7843
Guest
Posts: n/a
 
      10-12-2005
In article <(E-Mail Removed)>,
Jack Klein <(E-Mail Removed)> wrote:
> On 05 Oct 2005 14:14:03 +0100, John Devereux
> <(E-Mail Removed)> wrote in comp.lang.c:
>
> > I often see advice elsewhere, and in other peoples programs,
> > suggesting hiding all C "fundamental" types behind typedefs such as
> >
> > typedef char CHAR;
> > typedef char* PCHAR;

>
> This is more dangerous yes, never typedef a pointer this way. At
> least not if the pointer will ever be dereferenced using that alias.


What exactly is the danger you are alluding to here?
 
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
Preferred Size, Minimum Size, Size Jason Cavett Java 5 05-25-2008 08:32 AM
mega pixels, file size, image size, and print size - Adobe Evangelists Frank ess Digital Photography 0 11-14-2006 05:08 PM
equivalent c data types for vc++ data types ramu C Programming 2 02-20-2006 09:33 AM
size of a class having enumerated data types? ypjofficial@indiatimes.com C++ 8 01-23-2006 12:29 PM
Size of data types in C? siliconwafer C Programming 12 10-11-2005 03:35 PM



Advertisments