void printhex(const void *data,size_t len)
{
unsigned char * tmp = data;
while(tmp < &data[len]) //just warning , ??
printf("%.2X ",*tmp++);
printf("\n");
}

On Feb 3, 5:13 am, "Mark Jiao" <jzg1...@126.com> wrote:
> void printhex(const void *data,size_t len)
> {
> unsigned char * tmp = data;
> while(tmp < &data[len]) //just warning , ??
You are performing arithmetic operations with a void * pointer which
is not allowed.
&data[len] means &*(data + len)
Try this
--
while(tmp < (char *)data + len)

On 2ÔÂ3ÈÕ, ÉÏÎç11ʱ13·Ö, "Mark Jiao" <jzg1...@126.com> wrote:
> void printhex(const void *data,size_t len)
> {
> unsigned char * tmp = data;
> while(tmp < &data[len]) //just warning , ??
> printf("%.2X ",*tmp++);
> printf("\n");
>
>
>
> }- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
>
> - ÏÔʾÒýÓõÄÎÄ×Ö -

??

ÔÚ Sun, 03 Feb 2008 11:22:09 +0800£¬<vippstar@gmail.com> дµÀ:

> On Feb 3, 5:13 am, "Mark Jiao" <jzg1...@126.com> wrote:
>> void printhex(const void *data,size_t len)
>> {
>> unsigned char * tmp = data;
>> while(tmp < &data[len]) //just warning , ??
> You are performing arithmetic operations with a void * pointer which
> is not allowed.
> &data[len] means &*(data + len)
Sorry!
I am very poor English!
How many the memery address would be add?? 1? or No Standards ??

Thanks!
> Try this
> --
> while(tmp < (char *)data + len)



--

"Mark Jiao" <jzg1234@126.com> writes:
> void printhex(const void *data,size_t len)
> {
> unsigned char * tmp = data;
> while(tmp < &data[len]) //just warning , ??
> printf("%.2X ",*tmp++);
> printf("\n");
> }

I think what you're asking is why the compiler prints just a warning
rather than an error message.

Attempting to dereference a void*, as you've done here, is a
constraint violation. The compiler is required to issue some sort of
diagnostic message, but it doesn't have to be a fatal error (the
standard doesn't distinguish between warnings and other diagnostics).

As it happens, at least one major compiler allows, as an extension,
certain operations on void* that are not supported by the language.
If you're using gcc, that explains it.

Most warnings should be treated as errors anyway.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Mark Jiao wrote:
>
> ÔÚ Sun, 03 Feb 2008 11:22:09 +0800£¬<vippstar@gmail.com> дµÀ:
>
> > On Feb 3, 5:13 am, "Mark Jiao" <jzg1...@126.com> wrote:
> >> void printhex(const void *data,size_t len)
> >> {
> >> unsigned char * tmp = data;
> >> while(tmp < &data[len]) //just warning , ??
> > You are performing arithmetic operations with a void * pointer which
> > is not allowed.
> > &data[len] means &*(data + len)
> Sorry!
> I am very poor English!
> How many the memery address would be add?? 1? or No Standards ??

No Standards for ((void *)data + 1).

> > Try this
> > --
> > while(tmp < (char *)data + len)

1 memery address would be added for ((char *)data + 1).

--
pete

On Feb 3, 9:32 am, Keith Thompson <ks...@mib.org> wrote:
> "Mark Jiao" <jzg1...@126.com> writes:
> > void printhex(const void *data,size_t len)
> > {
> > unsigned char * tmp = data;
> > while(tmp < &data[len]) //just warning , ??
> > printf("%.2X ",*tmp++);
> > printf("\n");
> > }
>
> I think what you're asking is why the compiler prints just a warning
> rather than an error message.
>
> Attempting to dereference a void*, as you've done here, is a
> constraint violation. The compiler is required to issue some sort of
> diagnostic message, but it doesn't have to be a fatal error (the
> standard doesn't distinguish between warnings and other diagnostics).
I believe, since x[y] expands to (or, is equal to) *(x + y) what the
compiler should diagnose is about arithmetic on a 'void *' pointer.

On Sun, 03 Feb 2008 03:31:07 -0800, vippstar wrote:
> On Feb 3, 9:32 am, Keith Thompson <ks...@mib.org> wrote:
>> "Mark Jiao" <jzg1...@126.com> writes:
>> > void printhex(const void *data,size_t len) {
>> > unsigned char * tmp = data;
>> > while(tmp < &data[len]) //just warning , ??
>> > printf("%.2X ",*tmp++);
>> > printf("\n");
>> > }
>>
>> I think what you're asking is why the compiler prints just a warning
>> rather than an error message.
>>
>> Attempting to dereference a void*, as you've done here, is a constraint
>> violation. The compiler is required to issue some sort of diagnostic
>> message, but it doesn't have to be a fatal error (the standard doesn't
>> distinguish between warnings and other diagnostics).
> I believe, since x[y] expands to (or, is equal to) *(x + y) what the
> compiler should diagnose is about arithmetic on a 'void *' pointer.

You're correct. Dereferencing a void * is allowed, though not
particularly useful, since you can't do anything with the result but
discard it or take its address again. Performing arithmetic on a void *
is not allowed, because void is an incomplete type. It's the same as how
performing arithmetic on int (*)[] is not allowed, because int [] is an
incomplete type.

On Sun, 03 Feb 2008 12:47:45 +0100, Harald van D?k <truedfx@gmail.com>
wrote in comp.lang.c:

> On Sun, 03 Feb 2008 03:31:07 -0800, vippstar wrote:
> > On Feb 3, 9:32 am, Keith Thompson <ks...@mib.org> wrote:
> >> "Mark Jiao" <jzg1...@126.com> writes:
> >> > void printhex(const void *data,size_t len) {
> >> > unsigned char * tmp = data;
> >> > while(tmp < &data[len]) //just warning , ??
> >> > printf("%.2X ",*tmp++);
> >> > printf("\n");
> >> > }
> >>
> >> I think what you're asking is why the compiler prints just a warning
> >> rather than an error message.
> >>
> >> Attempting to dereference a void*, as you've done here, is a constraint
> >> violation. The compiler is required to issue some sort of diagnostic
> >> message, but it doesn't have to be a fatal error (the standard doesn't
> >> distinguish between warnings and other diagnostics).
> > I believe, since x[y] expands to (or, is equal to) *(x + y) what the
> > compiler should diagnose is about arithmetic on a 'void *' pointer.
>
> You're correct. Dereferencing a void * is allowed, though not

Allowed by whom? Certainly not by the C language standard. Can you
cite C&V to the contrary?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jack Klein <jackklein@spamcop.net> writes:
> On Sun, 03 Feb 2008 12:47:45 +0100, Harald van D?k <truedfx@gmail.com>
> wrote in comp.lang.c:
[...]
>> You're correct. Dereferencing a void * is allowed, though not
>
> Allowed by whom? Certainly not by the C language standard. Can you
> cite C&V to the contrary?

Can you cite C&V that says it's *not* allowed? I checked earlier, and
I was surprised to discover that it does appear to be allowed.

In C99 6.5.3.2, the only constraint for the unary "*" operator is:

The operand of the unary * operator shall have pointer type.

and void* is a pointer type. Obviously there's very little you can do
with the result, but this:

void *ptr = /* some non-null value */
*ptr;

appears to be legal (though not particularly useful).

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:

> In C99 6.5.3.2, the only constraint for the unary "*" operator is:
>
> The operand of the unary * operator shall have pointer type.
>
> and void* is a pointer type. Obviously there's very little you can do
> with the result, but this:
>
> void *ptr = /* some non-null value */
> *ptr;
>
> appears to be legal (though not particularly useful).

This has a curious consequence:
volatile void *ptr = SOMEWHERE;
*ptr;

How many bytes does that access?



--
Army1987 (Replace "NOSPAM" with "email")

Army1987 <army1...@NOSPAM.it> wrote:
> Keith Thompson wrote:
> > In C99 6.5.3.2, the only constraint for the unary "*"
> > operator is:
> >
> > The operand of the unary * operator shall have pointer
> > type. and void* is a pointer type. Obviously there's very
> > little you can do with the result, but this:
> >
> > void *ptr = /* some non-null value */
> > *ptr;
> >
> > appears to be legal (though not particularly useful).
>
> This has a curious consequence:
> volatile void *ptr = SOMEWHERE;
> *ptr;
>
> How many bytes does that access?

None. [How many bytes does any other void expression access?]

--
Peter

Peter Nilsson wrote:

> Army1987 <army1...@NOSPAM.it> wrote:
>> Â Â Âvolatile void *ptr = SOMEWHERE;
>> Â Â Â*ptr;
>>
>> How many bytes does that access?
>
> None. [How many bytes does any other void expression access?]
(void)memcpy(foo, bar, 42) accesses 42 bytes.



--
Army1987 (Replace "NOSPAM" with "email")

Army1987 wrote:

> (void)memcpy(foo, bar, 42) accesses 42 bytes.
84 bytes, I meant.

--
Army1987 (Replace "NOSPAM" with "email")

Army1987 <army1...@NOSPAM.it> wrote:
> Peter Nilsson wrote:
> > Army1987 <army1...@NOSPAM.it> wrote:
> > > volatile void *ptr = SOMEWHERE;
> > > *ptr;
> > >
> > > How many bytes does that access?
> >
> > None. [How many bytes does any other void expression
> > access?]
>
> (void)memcpy(foo, bar, 42) accesses [84] bytes.

How many bytes does the following access?

memcpy;

--
Peter

In article <fo6th2$mls$2@tdi.cu.mi.it>, Army1987 <army1987@NOSPAM.it> wrote:
>Army1987 wrote:

>> (void)memcpy(foo, bar, 42) accesses 42 bytes.

>84 bytes, I meant.

How do you arrive at that number? memcpy() does not define
the behaviour if the fields overlap. memmove() is the function
that defines the copying "as if" the data were copied into a
temporary buffer, and if such temporary copies were to take
place then Yes that would increase the byte count, but as you
have not defined the extent to which foo overlaps with bar,
you cannot say with any degree of certainty -exactly- how many
bytes would be accessed or how many times those bytes would be
accessed.
--
"Okay, buzzwords only. Two syllables, tops." -- Laurie Anderson

On Mon, 04 Feb 2008 14:08:56 -0800, Peter Nilsson wrote:
> How many bytes does the following access?
>
> memcpy;

None. You've got a function designator which is not the operand of sizeof
or &, so it automatically gets converted to a pointer to memcpy. Besides,
functions aren't objects, and don't have to be made up of bytes at all,
and in some cases really might not be -- consider a C program running on
a virtual machine, where memcpy is implemented as a system call to the
host.

On Mon, 04 Feb 2008 22:21:04 +0000, Walter Roberson wrote:
> In article <fo6th2$mls$2@tdi.cu.mi.it>, Army1987 <army1987@NOSPAM.it>
> wrote:
>>Army1987 wrote:
>
>>> (void)memcpy(foo, bar, 42) accesses 42 bytes.
>
>>84 bytes, I meant.
>
> How do you arrive at that number? memcpy() does not define the behaviour
> if the fields overlap.

So assuming the fields don't overlap, memcpy reads 42 bytes, and writes
42 different bytes, so accesses 84 bytes in total.

> Army1987 <army1...@NOSPAM.it> wrote:
> > Peter Nilsson wrote:
> > > Army1987 <army1...@NOSPAM.it> wrote:
> > > > volatile void *ptr = SOMEWHERE;
> > > > *ptr;
> > > >
> > > > How many bytes does that access?
> > >
> > > None. [How many bytes does any other void expression
> > > access?]
> >
> > (void)memcpy(foo, bar, 42) accesses [84] bytes.
<snip>

[In light of Harald van Dijk's point on my followup...]
How many bytes does the following access?

memcpy(foo, bar, 0);

If it's none, then why should *memcpy(foo, bar, 0) be
any different? If it isn't different, then why should
dereferencing a volatile void pointer be any different?

--
Peter

In article <1fad2$47a790c3$541dfcd3$20968@cache6.tilbu1.nb.ho me.nl>,
=?UTF-8?q?Harald_van_D=C4=B3k?= <truedfx@gmail.com> wrote:
>On Mon, 04 Feb 2008 22:21:04 +0000, Walter Roberson wrote:
>> In article <fo6th2$mls$2@tdi.cu.mi.it>, Army1987 <army1987@NOSPAM.it>
>> wrote:
>>>Army1987 wrote:

>>>> (void)memcpy(foo, bar, 42) accesses 42 bytes.

>>>84 bytes, I meant.

>> How do you arrive at that number? memcpy() does not define the behaviour
>> if the fields overlap.

>So assuming the fields don't overlap, memcpy reads 42 bytes, and writes
>42 different bytes, so accesses 84 bytes in total.

I must have been having a Duh moment.

Okay, so I'll turn it around: since the overlap of foo and bar is
not defined, we don't know that they occupy 42 distinct bytes each;
for example they might be offset by one byte from each other and
perhaps only 43 distinct bytes are accessed, 41 of them twice each.
The memcpy result is not defined for overlap, so we don't know
what the answer will be (fault for overlapping DMA perhaps), but
we can't say 84 bytes accessed for sure.

--
"Any sufficiently advanced bug is indistinguishable from a feature."
-- Rich Kulawiec

Walter Roberson wrote:
>> Army1987 wrote:
>
>>> (void)memcpy(foo, bar, 42) accesses 42 bytes.
>
>> 84 bytes, I meant.
>
> How do you arrive at that number? memcpy() does not define
> the behaviour if the fields overlap. memmove() is the function
.... snip ...

There is a from and a to parameter. They have restrict applied, so
they are different. Each points to a 42 byte area, which is either
examined or modified. 42 + 42 is roughly equal to 84. In base 10.

7.21.2.1 The memcpy function

Synopsis
[#1]
#include <string.h>
void *memcpy(void * restrict s1,
const void * restrict s2,
size_t n);
Description
[#2] The memcpy function copies n characters from the object
pointed to by s2 into the object pointed to by s1. If
copying takes place between objects that overlap, the
behavior is undefined.

Returns
[#3] The memcpy function returns the value of s1.

Please don't strip attributions for any material you quote.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

On Mon, 04 Feb 2008 18:46:13 -0500, CBFalconer wrote:
> Walter Roberson wrote:
[stripped attribution re-inserted]
>>In article <fo6th2$mls$2@tdi.cu.mi.it>, Army1987 <army1987@NOSPAM.it>
wrote:
>>> Army1987 wrote:
>>
>>>> (void)memcpy(foo, bar, 42) accesses 42 bytes.
>>
>>> 84 bytes, I meant.
>>
>> How do you arrive at that number? memcpy() does not define the
>> behaviour if the fields overlap. memmove() is the function
>
> Please don't strip attributions for any material you quote.

Please don't strip attributions for any material you quote. You stripped
attributions. Walter Roberson didn't, or at least not in the message you
replied to.

Peter Nilsson wrote:
> How many bytes does the following access?
>
> memcpy(foo, bar, 0);
>
> If it's none, then why should *memcpy(foo, bar, 0) be
> any different? If it isn't different, then why should
> dereferencing a volatile void pointer be any different?
Ok, another example:

volatile struct incomplete *foo = a_function_returning_a_struct_pointer();
*foo;
How many bytes does the statement access?


--
Army1987 (Replace "NOSPAM" with "email")

On Tue, 05 Feb 2008 16:46:26 +0000, Army1987 wrote:
> Peter Nilsson wrote:
>> How many bytes does the following access?
>>
>> memcpy(foo, bar, 0);
>>
>> If it's none, then why should *memcpy(foo, bar, 0) be any different? If
>> it isn't different, then why should dereferencing a volatile void
>> pointer be any different?
> Ok, another example:
>
> volatile struct incomplete *foo =
> a_function_returning_a_struct_pointer(); *foo;
> How many bytes does the statement access?

The behaviour is undefined, and no sane behaviour could be defined. Two
compilers I've tried generate an error, one warns and doesn't access any
bytes. (A fourth has problems with respecting the volatile keyword and
doesn't access any bytes even if the type is complete, but let's ignore
that one.) Quoting 6.3.2.1p2:
"Except when it is the operand of the sizeof operator, the unary &
operator, the ++ operator, the -- operator, or the left operand of the .
operator or an assignment operator, an lvalue that does not have array
type is converted to the value stored in the designated object (and is
no longer an lvalue). If the lvalue has qualified type, the value has the
unqualified version of the type of the lvalue; otherwise, the value has
the type of the lvalue. If the lvalue has an incomplete type and does
not have array type, the behavior is undefined."

This applies to struct incomplete but not to void *, because an
expression of type void is by definition never an lvalue, even if it is
the result of the unary * operator.