From: Randi Botse <nightdecoder@gmail.com>
To: linux-c-programming <linux-c-programming@vger.kernel.org>
Subject: Re: Pointer to a char
Date: Wed, 19 Sep 2012 14:59:40 +0700 [thread overview]
Message-ID: <CAA6iF_4qvxTyJi5Ex8hhURjttv94oVHrNxVzNXUWEEE0GHdcZA@mail.gmail.com> (raw)
In-Reply-To: <CADWT_cNu9u0Ni9aP0f3YBu6drLavU+ZY+kncG5Ae-BmcOEqk0g@mail.gmail.com>
Hi Phil, Jon
Thanks, now I'm clear with this, assignment doesn't care with type modifier.
Code such as
unsigned int j = 0xffeeddcc;
int i = j;
Both has the same value depending on how them interpreted (is this
assumption correct?)
Because,
printf("%u", i) will be different to printf("%i", i)
- but -
printf("%u", i) wlll be same as printf("%u", j)
Actually why asking this because I often see a pointer to a char* cast
Let me show you with this example.
Consider some structures...
struct a_data {
unsigned char f1[4];
unsigned char f2[6];
unsigned short f3[2];
};
and another struct named b_data, c_data, etc.
Then there is a general function to process all type of structure,
maybe something like this:
int process_data(char *buffer, size_t len);
Then if we cast for example a pointer to a_data struct to a char* as follow:
struct a_data a;
process_data((char*) &a, sizeof(a));
I though since it was cast to char*, the cast is "problem" because
every signed char buffer will have a range CHAR_MIN to CHAR_MAX,
therefore value of CHAR_MAX to UCHAR_MAX will broken (signed char
overflow)
I think process_data() should be declared with
int process_data(unsigned char *buffer, size_t len)
this declaration in seem correct and work for me.
However, now I'm conceptually understand why this works.
Thanks.
next prev parent reply other threads:[~2012-09-19 7:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-18 9:29 Pointer to a char Randi Botse
2012-09-18 10:29 ` Phil Sutter
2012-09-18 10:33 ` Duan Fugang-B38611
2012-09-19 1:04 ` Jon Mayo
2012-09-19 7:59 ` Randi Botse [this message]
2012-09-19 8:47 ` Leon Shaw
2012-09-19 18:09 ` Jon Mayo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA6iF_4qvxTyJi5Ex8hhURjttv94oVHrNxVzNXUWEEE0GHdcZA@mail.gmail.com \
--to=nightdecoder@gmail.com \
--cc=linux-c-programming@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).