memory of type void 
Author Message
 memory of type void

On 17 May 2003 03:35:04 GMT

Quote:




> >>The question is how can I have a memory block (not of any particular
> >>datatype) with a starting address and offsets. and how can I can use
> >>it in the program.

> > By treating it as an array of bytes (aka unsigned char).
> Can we always say that unsigned char will take 1 byte ? (I guess not)

By definition char and unsigned char are exactly 1 byte, however the
byte may be larger (but not smaller) than 8 bits.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Currently looking for a new job commutable from Slough, Berks, U.K.
Although my email address says spamtrap, it is real and I read it.
--



Sun, 06 Nov 2005 12:35:05 GMT  
 memory of type void
[...]

Quote:
> Can we always say that unsigned char will take 1 byte ? (I guess not)

Yes, absolutely.

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
--



Sun, 06 Nov 2005 12:35:16 GMT  
 memory of type void

[...]

Quote:
>Can we always say that unsigned char will take 1 byte ? (I guess not)

Well, "always" is a long time.  But in the current standard, by
definition, sizeof([signed|unsigned]char) == 1.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.
--



Sun, 06 Nov 2005 12:48:41 GMT  
 memory of type void

Quote:

> Well, "always" is a long time.  But in the current standard, by
> definition, sizeof([signed|unsigned]char) == 1.

Given that that was a deliberate decision and is now
"officially" embedded in a large amount of C code, it
is unlikely to ever change (for C).
--



Tue, 08 Nov 2005 04:08:11 GMT  
 memory of type void

Quote:

> On 02 May 2003 07:27:35 GMT, Subhek

> >Hi all

> >I am using C and I wish to store my data in memory of type void.

> >I have intialized a void pointer and malloc some bytes to it and now i want
> >to store my integer and char data to that memory how can i do that?

> >The program below is not correct but it gives a fairly good picture of what
> >I want to do.

> >I want a big memory to be allocated as a generic memory. Then I want to
> >access it as and when I want to. Here I want to store a char at 10th byte
> >and an int at 80th.

> >#include<stdio.h>
> >void main()
> >{
> >        void *msg1;
> >        int a = 4;
> >        char b = 'a';
> >        msg1 = malloc(100);

> If malloc succeeds, the value in msg1is guaranteed to be aligned
> properly for any (or every) type.  But you really ought to check.

Only msg1, not (char *)msg1 + [1..99]

Quote:
> >        *(int)(msg1+80) = a;

> Ditto except now the cast is int*.

> But you also have another problem.  You allocated 100 bytes of space.
> You are trying to store into the 80th int in that space.  On many
> system, an int is at least four bytes.  In order to do this, you would
> need to allocate at least 324 bytes.

No, there's precedence issues, plus pointer arithmetic is illegal:
*(int *)((unsigned char *)msg1 + 79) = a; is more likely to work, but
cannot be guarenteed.
--



Wed, 09 Nov 2005 02:34:54 GMT  
 memory of type void

Quote:



> >>The question is how can I have a memory block (not of any particular
> >>datatype) with a starting address and offsets. and how can I can use
> >>it in the program.

> > By treating it as an array of bytes (aka unsigned char).
>  Can we always say that unsigned char will take 1 byte ? (I guess not)

By definition, yes. unsigned char is defined to be one byte in size.
Note that a byte may not be an octet.
--



Wed, 09 Nov 2005 02:35:02 GMT  
 memory of type void

Quote:

> Hi all

> Thanks for your replies.

> It seems I was not able to put up my problem clearly.
> I dont want a debug version of the code below.

> The question is how can I have a memory block (not of any particular
> datatype) with a starting address and offsets. and how can I can use
> it in the program.

> Anyways I have found a work around.

Just out of curiosity, why did you need this?

Quote:
> P.S. : a note to the moderator:: I was not able to cancel this
> article, please do it for me.

There is no moderator here, and it's bad form to cancel articles
unless they were accidentally sent.
--



Wed, 09 Nov 2005 02:35:15 GMT  
 memory of type void

Quote:

> There is no moderator here, ...

You're posting to comp.lang.c.moderated, there's certainly a moderator
here.

Quote:
> ... and it's bad form to cancel articles
> unless they were accidentally sent.

Since when?

--

 __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/  \ No one knows what he can do until he tries.
\__/  Publilius Syrus
--



Wed, 09 Nov 2005 13:31:18 GMT  
 memory of type void
[...]

Quote:
> There is no moderator here, and it's bad form to cancel articles
> unless they were accidentally sent.
> --


Um, yes there is; note the name of the newsgroup.

[I didn't have the heart to tell him. -mod]

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
--



Wed, 09 Nov 2005 13:31:34 GMT  
 memory of type void


Quote:



> > >>The question is how can I have a memory block (not of any particular
> > >>datatype) with a starting address and offsets. and how can I can use
> > >>it in the program.

> > > By treating it as an array of bytes (aka unsigned char).
> >  Can we always say that unsigned char will take 1 byte ? (I guess not)

> By definition, yes. unsigned char is defined to be one byte in size.
> Note that a byte may not be an octet.
> --

Note that some archetectures cannot address bytes. Analog Devices 16 bit DSP
are one example. In these cases you will find char occupies one 16 bit word,
sizeof(char) = sizeof(int) = 1 (one word).

Graham
--



Fri, 11 Nov 2005 01:22:46 GMT  
 memory of type void
[...]

Quote:
> Note that some archetectures cannot address bytes. Analog Devices 16 bit DSP
> are one example. In these cases you will find char occupies one 16 bit word,
> sizeof(char) = sizeof(int) = 1 (one word).

On such a system, a byte (as the term is used in the C standard) is 16
bits.

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
--



Fri, 11 Nov 2005 12:13:46 GMT  
 memory of type void

Quote:
>Note that some archetectures cannot address bytes.

The abstract C machine can, even on such architectures.

Quote:
>Analog Devices 16 bit DSP
>are one example. In these cases you will find char occupies one 16 bit word,
>sizeof(char) = sizeof(int) = 1 (one word).

That's a trivial case.  The C implementation's byte has 16 bits.

Less trivial cases are the C implementations on the original Cray vector
processors (the processor only supported 64-bit accesses, but the C
implementation had 8-bit bytes) and the first Alpha processors (the
2106x chips, which supported only 32 and 64-bit accesses, but the C
implementation had 8-bit bytes).

Dan
--
Dan Pop
DESY Zeuthen, RZ group

--



Sun, 13 Nov 2005 00:26:13 GMT  
 memory of type void

Quote:

writes:

> >Note that some archetectures cannot address bytes.

> The abstract C machine can, even on such architectures.

Interesting, thanks for the follow-up. Presumably that involves a bit shift
and AND operations for 50% of byte addresses (75% on 32 bit, 87.5% on 64
bit). Valuable if storage is at a premium but it would seem the programmers
of these machines would need to avoid using char/byte if execution speed was
most important.
It seems beter to me to put the byte packing under the programmers explicit
control.

Graham
--



Sun, 13 Nov 2005 05:38:13 GMT  
 memory of type void

Quote:




> writes:

> > >Note that some archetectures cannot address bytes.

> > The abstract C machine can, even on such architectures.

> Interesting, thanks for the follow-up. Presumably that involves a bit shift
> and AND operations for 50% of byte addresses (75% on 32 bit, 87.5% on 64
> bit). Valuable if storage is at a premium but it would seem the programmers
> of these machines would need to avoid using char/byte if execution speed was
> most important.
> It seems beter to me to put the byte packing under the programmers explicit
> control.

Remember that a byte, in the sense used by the C standard, must be at
least 8 bits, but can be bigger.

A C implementation on a machine that cannot directly address 8-bit
quantities has two options.  (Dan mentioned both, but you snipped a
bit too much of his reply to make that clear.)

For a 16-bit DSP, it might make sense to use 16-bit bytes
(CHAR_BIT == 16, UCHAR_MAX == 65535, etc.).  This maps nicely onto the
hardware, but makes it difficult to represent 8-bit quantities.  Presumably
any software you want to compile for such a system won't be using
any 8-bit quantities.

For Cray vector computers, Cray made the choice to have 8-bit bytes
(CHAR_BIT == 8, UCHAR_MAX == 255), and to use 64 bits for short, int,
and long (and perhaps long long, but I don't think they have a C99
compiler).  They could have used 64-bit bytes, setting CHAR_BIT to 64
and sizeof(int) to 1, but that would have made porting software
written for other systems a major pain.

They could conceivably have had the best of both worlds if they had
been able to have 8-bit characters and 64-bit bytes, but C doesn't let
you do that.

--

San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
--



Mon, 14 Nov 2005 11:16:55 GMT  
 memory of type void

Quote:



>writes:

>> >Note that some archetectures cannot address bytes.

>> The abstract C machine can, even on such architectures.

>Interesting, thanks for the follow-up. Presumably that involves a bit shift
>and AND operations for 50% of byte addresses (75% on 32 bit, 87.5% on 64
>bit). Valuable if storage is at a premium but it would seem the programmers
>of these machines would need to avoid using char/byte if execution speed was
>most important.
>It seems beter to me to put the byte packing under the programmers explicit
>control.

You forget an important issue: how much of the existing C software would
still work on an implementation with 32 or 64-bit characters, where octet
packing is under the programmer's explicit control?  How many people
would want to use such a *hosted* implementation?

Dan
--
Dan Pop
DESY Zeuthen, RZ group

--



Mon, 14 Nov 2005 11:17:00 GMT  
 
 [ 30 post ]  Go to page: [1] [2] [3]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software