linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Shaw <shaw.leon@gmail.com>
To: Randi Botse <nightdecoder@gmail.com>
Cc: linux-c-programming <linux-c-programming@vger.kernel.org>
Subject: Re: Pointer to a char
Date: Wed, 19 Sep 2012 16:47:55 +0800	[thread overview]
Message-ID: <CABAhCOTPLJWTwb=Oqnhpz3D8zoW+aAnCYd6quTXYPXhA2beOKQ@mail.gmail.com> (raw)
In-Reply-To: <CAA6iF_4qvxTyJi5Ex8hhURjttv94oVHrNxVzNXUWEEE0GHdcZA@mail.gmail.com>

On Wed, Sep 19, 2012 at 3:59 PM, Randi Botse <nightdecoder@gmail.com> wrote:
> 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?)
>

According to C99, when applying integer conversion, "if the new type
is signed and the value cannot be represented in it, either the result
is implementation-defined or an implementation-defined signal is
raised". But most implementation keeps the same memory representation.

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

Actually, whether char is signed or unsigned is
implementation-defined, though, normally, it is signed. SCHAR_MAX+1 ~
UCHAR_MAX can be mapped to SCHAR_MIN ~ -1.
For a pointer that denotes a memory region, what type it points to
doesn't cause much problem as long as you don't simply dereference it.
In such cases, void * might be less confusing.

Regards,
Leon


> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-09-19  8:47 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
2012-09-19  8:47     ` Leon Shaw [this message]
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='CABAhCOTPLJWTwb=Oqnhpz3D8zoW+aAnCYd6quTXYPXhA2beOKQ@mail.gmail.com' \
    --to=shaw.leon@gmail.com \
    --cc=linux-c-programming@vger.kernel.org \
    --cc=nightdecoder@gmail.com \
    /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).