Hello,
Are all pointer types the same length? My instinct tells me yes,
but I just wanted to confirm with the experts. So if I have
typedef struct {
char* field1;
int field2;
} myStruct;
myStruct *a;
char *b;
int *c;
Are the variables "a", "b", and "c" all 32 bits in length? Thanks, -
Dave
24  1420  la***********@zipmail.com wrote: Hello,
Are all pointer types the same length? My instinct tells me yes,
but I just wanted to confirm with the experts. So if I have
typedef struct {
char* field1;
int field2;
} myStruct;
myStruct *a;
char *b;
int *c;
Are the variables "a", "b", and "c" all 32 bits in length? Thanks, -
yes
you can check this with sizeof( char* ) and so on.
Regards,
Daniel
Dave la***********@zipmail.com wrote: Hello,
Are all pointer types the same length?
ITYM "size"
My instinct tells me yes,
but I just wanted to confirm with the experts. So if I have
[snip]
myStruct *a;
char *b;
int *c;
Are the variables "a", "b", and "c" all 32 bits in length? Thanks, -
No, the size is not specified in either case.
There are four groups of pointers that are required to have the
same representation and alignment (hence size, too): pointers to
1) un/qualified compatible types; 2) void and character types; 3)
struct types; 4) union types.
So, for an example, in theory
unsigned int *up;
signed int *sp;
`up' and `sp' might have different sizes (and other properties).
--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Daniel Etzold <de*****@gmx.net> wrote: la***********@zipmail.com wrote:
myStruct *a;
char *b;
int *c;
Are the variables "a", "b", and "c" all 32 bits in length? Thanks, -
yes
Goodness, NO! See my other reply.
--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g` la***********@zipmail.com wrote:
Hello,
Are all pointer types the same length?
They don't have to be.
(char *) and (void *) have the same representation.
Pointers to struct types are all the same size as each other.
Other types can be different.
myStruct *a;
char *b;
int *c;
Are the variables "a", "b", and "c" all 32 bits in length?
At your house? Maybe, I don't know. Everywhere else, maybe not
#include <stdio.h>
printf("sizeof (int *) is %lu.\n", (long unsigned)sizeof(int *));
printf("sizeof (char*) is %lu.\n", (long unsigned)sizeof(char*));
--
pete la***********@zipmail.com wrote: Hello,
Are all pointer types the same length? My instinct tells me yes,
but I just wanted to confirm with the experts. So if I have
typedef struct {
char* field1;
int field2;
} myStruct;
myStruct *a;
char *b;
int *c;
Are the variables "a", "b", and "c" all 32 bits in length? Thanks, -
As far as the standard is concerned they could all be different lengths
and using different representations. There is also no guarantee that an
implementation has *any* type which will be 32 bits in length.
The only reasons I can think of for needing to know what you are asking
are somewhat obscure. So I strongly suspect that you are approaching
whatever your real problem is in the wrong way.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
On 18 Apr 2005 06:37:53 -0700, la***********@zipmail.com
<la***********@zipmail.com> wrote: Are all pointer types the same length? My instinct tells me yes,
but I just wanted to confirm with the experts. So if I have
They may be, but they needn't be. All that is required is that void*
has the same representation as char*.
typedef struct {
char* field1;
int field2;
} myStruct;
myStruct *a;
char *b;
int *c;
Are the variables "a", "b", and "c" all 32 bits in length?
On what platform? They could be all different lengths, or all 64 bits
(or 16, or 24, or any other number depending on the architecture).
For instance, take a word-addressed machine which addresses in 32 bit
words. If a char is 8 bits on such a machine, a char pointer (and
therefore also a void*) would need extra information to store which char
in the word is addressed. At least one CPU allowed memory to be
addressed as bit fields with a start position and a length, that could
have totally different sizes of pointers for different types.
Chris C
Yes all the pointers are of same size . "Internally" they all are
actully of type unsigned int , though u can specify them as what ever
datatype . What actully is a pointer , just a way to access the memory
address directly which obviuosly is of type unsigned int.
struct abc
{
--------
}*ptr1;
char * ptr2;
both ptr1 and ptr2 (though of incompatible types) have the same size
i.e equal to unsigned int, As far as different platforms are
concerned.The size of unsigned int varies from platform to platform ,
correspondingly the size of the pointers change.
Prashant Mahajan
Prashant Mahajan wrote:
Yes all the pointers are of same size . "Internally" they all are
actully of type unsigned int , though u can specify them as what ever
datatype . What actully is a pointer , just a way to access the memory
address directly which obviuosly is of type unsigned int.
struct abc
{
--------
}*ptr1;
char * ptr2;
both ptr1 and ptr2 (though of incompatible types) have the same size
i.e equal to unsigned int, As far as different platforms are
concerned.The size of unsigned int varies from platform to platform ,
correspondingly the size of the pointers change.
Your post is pure fantasy.
--
pete
"Prashant Mahajan" <mr***************@gmail.com> writes: Yes all the pointers are of same size .
This is often true on many systems, but it absolutely is not
guaranteed by the standard. There are good reasons why void* and
char* pointers might be bigger than int* pointers on some
architectures; similarly function pointers might be represented
differently than object pointers.
"Internally" they all are
actully of type unsigned int , though u can specify them as what ever
datatype . What actully is a pointer , just a way to access the memory
address directly which obviuosly is of type unsigned int.
No. As far as the language in concerned, pointers and integers are
distinct types, though conversions between them are allowed in some
limited circumstances. It is not at all "obvious" that a memory
address is of type unsigned int.
I've worked on several systems on which unsigned int is 32 bits and
pointers are 64 bits (and I expect such systems to become more common
over time).
C99 defines (in <stdint.h>) types intptr_t and uintptr_t that are big
enough to hold object pointer values. It's important to note that
these types are optional, that they aren't necessarily the same size
as an object pointer, and that they can't necessarily hold function
pointer values.
[snip]
Prashant, may I ask where you got your information?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
.... Prashant, may I ask where you got your information?
Answer: From experience.
Hint: Not everybody genuflects at the altar of the standard. In fact,
I would wager that Prashant has never even heard of "the standard".
In article <42***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:
.... both ptr1 and ptr2 (though of incompatible types) have the same size
i.e equal to unsigned int, As far as different platforms are
concerned.The size of unsigned int varies from platform to platform ,
correspondingly the size of the pointers change.
Your post is pure fantasy.
No. In fact, his post is quite reasonable. His only error was neglecting
to include an obvious qualification, which I'm sure to him seemed so
obvious that he couldn't imagine people not assuming same.
That qualification goes something like:
On garden variety 32 bit Intel hardware, using normal compilers on
normal OSs. I.e., all the systems I (Prashant) have ever used.
P.S. Yes, I am well aware that there are words in the previous sentence
that clc pissant regulars can (and will) quibble with. Have a ball! ga*****@yin.interaccess.com (Kenny McCormack) writes: In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
...Prashant, may I ask where you got your information?
Answer: From experience.
Hint: Not everybody genuflects at the altar of the standard. In fact,
I would wager that Prashant has never even heard of "the standard".
_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `'
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Prashant Mahajan wrote: Yes all the pointers are of same size . "Internally" they all
are actully of type unsigned int , though u can specify them as
what ever datatype . What actully is a pointer , just a way to
access the memory address directly which obviuosly is of type
unsigned int.
Having programmed on a system where unsigned int is 2 bytes and
char * is 3 bytes, I can only say: "Pooh to you with knobs on!"
Old Wolf wrote: Prashant Mahajan wrote:
Yes all the pointers are of same size . "Internally" they all
are actully of type unsigned int , though u can specify them as
what ever datatype . What actully is a pointer , just a way to
access the memory address directly which obviuosly is of type
unsigned int.
Having programmed on a system where unsigned int is 2 bytes and
char * is 3 bytes, I can only say: "Pooh to you with knobs on!"
I'll bite: Can you tell us more about this system?
It sounds like it might have been the DS09000 (DeathStation
Octal Oh-Nine-Thousand, with an implementation-dependent
interpretation of the non-octal digit "nine").
--
Eric Sosman es*****@acm-dot-org.invalid
On Tue, 19 Apr 2005 20:57:43 -0400, Eric Sosman
<es*****@acm-dot-org.invalid> wrote: Old Wolf wrote: Prashant Mahajan wrote:
Yes all the pointers are of same size . "Internally" they all
are actully of type unsigned int , though u can specify them as
what ever datatype . What actully is a pointer , just a way to
access the memory address directly which obviuosly is of type
unsigned int.
Having programmed on a system where unsigned int is 2 bytes and
char * is 3 bytes, I can only say: "Pooh to you with knobs on!"
I'll bite: Can you tell us more about this system?
It sounds like it might have been the DS09000 (DeathStation
Octal Oh-Nine-Thousand, with an implementation-dependent
interpretation of the non-octal digit "nine").
I don't know about his machine but I work on big-endian one where all
pointers are 24 bits (with 8 padding bits on the high end) and all
unsigned ints are 32 bits. Originally manufactured by IBM as a
derivative of the commercial S/360 (yes, it is over 30 years old).
<<Remove the del for email>>
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote: /| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
Assuming, for the sake of argument, that you are calling me a troll, then
aren't you in direct violation of your own statement? ga*****@yin.interaccess.com (Kenny McCormack) wrote: In article <42***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:
... both ptr1 and ptr2 (though of incompatible types) have the same size
i.e equal to unsigned int, As far as different platforms are
concerned.The size of unsigned int varies from platform to platform ,
correspondingly the size of the pointers change.
Your post is pure fantasy.
No. In fact, his post is quite reasonable. His only error was neglecting
to include an obvious qualification, which I'm sure to him seemed so
obvious that he couldn't imagine people not assuming same.
That qualification goes something like:
On garden variety 32 bit Intel hardware, using normal compilers on
normal OSs. I.e., all the systems I (Prashant) have ever used.
In other words,
In my limited experience, which doesn't even go back as far as
MS-DOS, and is therefore hardly a guarantee in the real world.
P.S. Yes, I am well aware that there are words in the previous sentence
that clc pissant regulars can (and will) quibble with. Have a ball!
How about the entire sentence?
Richard
Eric Sosman wrote: Old Wolf wrote:What actully is a pointer , just a way to access the memory
address directly which obviuosly is of type unsigned int.
Having programmed on a system where unsigned int is 2 bytes and
char * is 3 bytes,
I'll bite: Can you tell us more about this system?
It was an Intel 8051 CPU (8-bit), with three different address
spaces: 64K of data, 64K of code, and 128 bytes of registers.
Ints were 16 bits (2 bytes). You could declare a code pointer
or a data pointer of 2 bytes, using a compiler extension keyword,
but to have a pointer that could be pointing to any of those
three pages, required 2 extra significant bits (hence the third byte).
"Old Wolf" <ol*****@inspire.net.nz> writes: Eric Sosman wrote: Old Wolf wrote: >
>>What actully is a pointer , just a way to access the memory
>>address directly which obviuosly is of type unsigned int.
>
> Having programmed on a system where unsigned int is 2 bytes and
> char * is 3 bytes,
I'll bite: Can you tell us more about this system?
It was an Intel 8051 CPU (8-bit), with three different address
spaces: 64K of data, 64K of code, and 128 bytes of registers.
Ints were 16 bits (2 bytes). You could declare a code pointer
or a data pointer of 2 bytes, using a compiler extension keyword,
but to have a pointer that could be pointing to any of those
three pages, required 2 extra significant bits (hence the third byte).
There would be no need for a char* to be able to point into the code
space (unless the compiler supports meaningful conversions between
char* and function pointers as an extension). Pointing into the
register space could be useful, of course (but again it's probably not
required for C semantics).
Out of curiosity, was this extended pointer format implemented in
hardware or in software? I know it doesn't matter as far as the C
language is concerned, but it would be nice to have more ammunition
against the assumption that a C pointer is always a hardware address.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
On Thu, 21 Apr 2005 01:23:48 GMT, Keith Thompson <ks***@mib.org>
wrote: "Old Wolf" <ol*****@inspire.net.nz> writes: Eric Sosman wrote: Old Wolf wrote:
>
>>What actully is a pointer , just a way to access the memory
>>address directly which obviuosly is of type unsigned int.
>
> Having programmed on a system where unsigned int is 2 bytes and
> char * is 3 bytes,
I'll bite: Can you tell us more about this system?
It was an Intel 8051 CPU (8-bit), with three different address
spaces: 64K of data, 64K of code, and 128 bytes of registers.
Ints were 16 bits (2 bytes). You could declare a code pointer
or a data pointer of 2 bytes, using a compiler extension keyword,
but to have a pointer that could be pointing to any of those
three pages, required 2 extra significant bits (hence the third byte).
There would be no need for a char* to be able to point into the code
space (unless the compiler supports meaningful conversions between
char* and function pointers as an extension). Pointing into the
register space could be useful, of course (but again it's probably not
required for C semantics).
The names 'code space' and 'data space' are not quite accurate.
As far as the compiler is concerned, all ROM is in the 'code space'
and all (volatile) RAM is in the 'data space'. The compilers for the
8051 CPU allow one to store constant data in the 'code space', so it
is meaningful to have data pointers that point into the code space.
Bart v Ingen Schenau
On Thu, 21 Apr 2005 01:23:48 +0000, Keith Thompson wrote: "Old Wolf" <ol*****@inspire.net.nz> writes: Eric Sosman wrote:
It was an Intel 8051 CPU (8-bit), with three different address spaces:
64K of data, 64K of code, and 128 bytes of registers. Ints were 16 bits
(2 bytes). You could declare a code pointer or a data pointer of 2
bytes, using a compiler extension keyword, but to have a pointer that
could be pointing to any of those three pages, required 2 extra
significant bits (hence the third byte).
There would be no need for a char* to be able to point into the code space
(unless the compiler supports meaningful conversions between char* and
function pointers as an extension). Pointing into the register space
could be useful, of course (but again it's probably not required for C
semantics).
If it is the same compiler I am using for the 8051 (Keil compiler) it is
easyer to think of them as pointers to RAM, ROM and registers. So you want
to be able to use pointers to code space for constants, for two resons.
You do not have space in the RAM for copies of the constants, and you do
not have the time at start up to copy all the constants into RAM.
Out of curiosity, was this extended pointer format implemented in hardware
or in software? I know it doesn't matter as far as the C language is
concerned, but it would be nice to have more ammunition against the
assumption that a C pointer is always a hardware address.
It is done in the software as functions which are called whenever you
reference a pointer. Which is why on this complier you should try and
aviod generic pointers.
Kevin Bagust.
In article <42**************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote: ga*****@yin.interaccess.com (Kenny McCormack) wrote:
In article <42***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:
... >> both ptr1 and ptr2 (though of incompatible types) have the same size
>> i.e equal to unsigned int, As far as different platforms are
>> concerned.The size of unsigned int varies from platform to platform ,
>> correspondingly the size of the pointers change.
>
>Your post is pure fantasy.
No. In fact, his post is quite reasonable. His only error was neglecting
to include an obvious qualification, which I'm sure to him seemed so
obvious that he couldn't imagine people not assuming same.
That qualification goes something like:
On garden variety 32 bit Intel hardware, using normal compilers on
normal OSs. I.e., all the systems I (Prashant) have ever used.
In other words,
In my limited experience, which doesn't even go back as far as
MS-DOS, and is therefore hardly a guarantee in the real world.
You got it.
The point, of course, is that with suitable qualifiers, any statement can
be made to be true. P.S. Yes, I am well aware that there are words in the previous sentence
that clc pissant regulars can (and will) quibble with. Have a ball!
How about the entire sentence?
Thank you for proving my point.
In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> writes:
but it would be nice to have more ammunition
against the assumption that a C pointer is always a hardware address.
There's always the good ol' AS/400.
For anyone who's missed this discussion in the past: On the 400,
hardware addresses are 64 bits but C pointers are 128 bits. (In the
versions I've worked with, the largest integer types were 32-bit; I
think 64-bit integers are available now, but you still can't cram a
pointer into any sort of integer type.) Of course, like other
application programming languages on the 400 (as opposed to those
used to write the 400's Licensed Internal Code), C is compiled to the
MI pseudo-assembly language, which also uses the 128-bit "addresses".
The translation to 64-bit hardware addresses happens lower down.
(This doesn't apply to the 400's PASE environment, which gives
processes a more traditional private 64-bit address space, rather
than letting them play in the 128-bit "single-level store" shared
address space. Or so I've heard.)
--
Michael Wojcik mi************@microfocus.com
She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster ga*****@yin.interaccess.com (Kenny McCormack) wrote: In article <42**************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:ga*****@yin.interaccess.com (Kenny McCormack) wrote:
That qualification goes something like:
On garden variety 32 bit Intel hardware, using normal compilers on
normal OSs. I.e., all the systems I (Prashant) have ever used.
In other words,
In my limited experience, which doesn't even go back as far as
MS-DOS, and is therefore hardly a guarantee in the real world.
You got it.
The point, of course, is that with suitable qualifiers, any statement can
be made to be true.
So. You didn't have any real information, you just wanted to be contrary
for the sake of it. Glad to have cleared that up.
Richard This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Rob Somers |
last post by:
Hey all
I am writing a program to keep track of expenses and so on - it is not
a school project, I am learning C as a hobby - At any rate, I am new
to structs and reading and writing to files,...
|
by: Ross A. Finlayson |
last post by:
I'm trying to write some C code, but I want to use C++'s std::vector.
Indeed, if the code is compiled as C++, I want the container to
actually be std::vector, in this case of a collection of value...
|
by: sunglo |
last post by:
Some time a go, in a discussion here in comp.lang.c, I learnt that it's
better not to use a (sometype **) where a (void **) is expected (using
a cast). Part of the discussion boiled down to the...
|
by: Claudio Grondi |
last post by:
In the process of learning about some deeper details of Python I am
curious if it is possible to write a 'prefix' code assigning to a and b
something special, so, that Python gets trapped in an...
|
by: James Dow Allen |
last post by:
The gcc compiler treats malloc() specially! I have no
particular question, but it might be fun to hear from
anyone who knows about gcc's special behavior.
Some may find this post interesting;...
|
by: dotNeter |
last post by:
I'm studying the RTTI, and my current work is concern for how to get
the self-defined type at runtime, that's exactly what the RTTI does.
I mean, in my application, I built several self-defined...
|
by: Michael |
last post by:
Hi,
I am trying to pass a function an array of strings, but I am having trouble
getting the indexing to index the strings rather than the individual
characters of one of the strings.
I have...
|
by: Michael Goldshteyn |
last post by:
Consider the following two lines of code, the first intended to print "Hello
world\n" and the second intended to print the character 'P' to stdout.
---
std::cout <<...
|
by: alex.j.k2 |
last post by:
Hello all,
I have "PRECISION" defined in the preprocessor code
and it could be int, float or double, but I do not know in the
code what it is.
Now if I want to assign zero to a "PRECISION"...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
