linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).