Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > memcpy() where assignment would do?

Reply
Thread Tools

memcpy() where assignment would do?

 
 
kuyper
Guest
Posts: n/a
 
      08-23-2007
I've run across some rather peculiar code; here are the relevant lines
that left me confused :

unsigned char cr_file[384];
unsigned char num_char[0];

Note: this declaration actually works on our compiler, and it appears
to be equivalent to giving a length of 1. The developer inserted
compiler options into the make file to turn off the relevant warning
messages. Sadly, this is not the most confusing part of the code. This
is an example of the confusing part:

num_char[0] = 1;
memcpy(&cr_file[147], num_char, 1);

num_char is used only in this fashion; its value after the call to
memcpy() has no bearing on the behavior of the program. I may be
missing something, but it seems to me that this code is therefore
exactly equivalent to

cr_file[147] = 1;

In fact, I would expect that some compilers would generate identical
code for both ways of writing it.

Am I missing something? If not, could someone at least suggest a
plausible reason why the developer might write such bizarre code? I
can't ask the developer, he died recently, which is how I became
responsible for this code.

 
Reply With Quote
 
 
 
 
Jensen Somers
Guest
Posts: n/a
 
      08-23-2007
Hi,

On Thu, 23 Aug 2007 08:27:34 -0700, kuyper wrote:

> I've run across some rather peculiar code; here are the relevant lines
> that left me confused :
>
> unsigned char cr_file[384];
> unsigned char num_char[0];


IIRC, this is a GCC extension. I had problems with this when using the
Microsoft Visual C compiler (which still uses some fork of the ISO89
standard). After further investigation it turned out this seemed to be an
extension and should throw a warning/error when compiling the --pedantic.

Jensen.
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      08-23-2007
kuyper wrote On 08/23/07 11:27,:
> I've run across some rather peculiar code; here are the relevant lines
> that left me confused :
>
> unsigned char cr_file[384];
> unsigned char num_char[0];
>
> Note: this declaration actually works on our compiler, and it appears
> to be equivalent to giving a length of 1. The developer inserted
> compiler options into the make file to turn off the relevant warning
> messages. Sadly, this is not the most confusing part of the code. This
> is an example of the confusing part:
>
> num_char[0] = 1;
> memcpy(&cr_file[147], num_char, 1);
>
> num_char is used only in this fashion; its value after the call to
> memcpy() has no bearing on the behavior of the program. I may be
> missing something, but it seems to me that this code is therefore
> exactly equivalent to
>
> cr_file[147] = 1;
>
> In fact, I would expect that some compilers would generate identical
> code for both ways of writing it.
>
> Am I missing something? If not, could someone at least suggest a
> plausible reason why the developer might write such bizarre code? I
> can't ask the developer, he died recently, which is how I became
> responsible for this code.


A guess: The bogus definition of num_char[0] may
actually allocate memory as would num_char[1], but has
some other bizarre effect as well. If it didn't do
something unusual the programmer would have written [1]
in the first place, instead of writing [0] and then
going to the extra work of figuring out how to turn the
error message off. The use of memcpy() instead of
`cr_file[147] = num_char[0]' or `cr_file[147] = 1' may
have something to do with whatever that weird effect is.

Guess #2: Does the code call "the" memcpy(), or some
out-of-the-blue substitute? Writing your own substitutes
for Standard library functions is a no-no, but we've
already seen that the author didn't feel held bound to
respect the Standard at all times ...

Guess #3: Somewhere in the dusty annals of the code's
ancestry you will find the word IOCCC -- or was it XYZZY?

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Mark Bluemel
Guest
Posts: n/a
 
      08-23-2007
kuyper wrote:
> I've run across some rather peculiar code; here are the relevant lines
> that left me confused :
>
> unsigned char cr_file[384];
> unsigned char num_char[0];
>
> Note: this declaration actually works on our compiler, and it appears
> to be equivalent to giving a length of 1. The developer inserted
> compiler options into the make file to turn off the relevant warning
> messages. Sadly, this is not the most confusing part of the code. This
> is an example of the confusing part:
>
> num_char[0] = 1;
> memcpy(&cr_file[147], num_char, 1);
>
> num_char is used only in this fashion; its value after the call to
> memcpy() has no bearing on the behavior of the program. I may be
> missing something, but it seems to me that this code is therefore
> exactly equivalent to
>
> cr_file[147] = 1;
>
> In fact, I would expect that some compilers would generate identical
> code for both ways of writing it.


I'd be inclined to investigate what my compiler generated for each of
these constructs and look at what the differences might imply...

As you have given us very little context - platform, compiler, etc -
unless someone here has seen exactly this, it's unlikely we can comment
much more.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-23-2007
Jensen Somers wrote:
> kuyper wrote:
>
>> I've run across some rather peculiar code; here are the relevant
>> lines that left me confused :
>>
>> unsigned char cr_file[384];


Yhis defines an array of 384 unsigned chars, indices 0 through 383.

>> unsigned char num_char[0];


This is illegal. 0 size arrays cannot be declared.

I am piggybacking this reply.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



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

 
Reply With Quote
 
kuyper
Guest
Posts: n/a
 
      08-23-2007
Eric Sosman wrote:
....
> A guess: The bogus definition of num_char[0] may
> actually allocate memory as would num_char[1], but has
> some other bizarre effect as well. If it didn't do
> something unusual the programmer would have written [1]
> in the first place, instead of writing [0] and then
> going to the extra work of figuring out how to turn the
> error message off. The use of memcpy() instead of
> `cr_file[147] = num_char[0]' or `cr_file[147] = 1' may
> have something to do with whatever that weird effect is.


That would make sense; but it seems very unlikely. On the other hand,
up until yesterday, I would have said that code like this was very
unlikely. :-}

It will be easy to test for this. I intend to replace the odd code
with more conventional code. If you're first guess is correct, the
resulting output files won't match those created with the original
code. I'll be performing that test sometime today or tomorrow.

> Guess #2: Does the code call "the" memcpy(), or some
> out-of-the-blue substitute? Writing your own substitutes
> for Standard library functions is a no-no, but we've
> already seen that the author didn't feel held bound to
> respect the Standard at all times ...


There's no alternative definition of memcpy() in the source code, and
it doesn't link to any libraries that might contain one.

 
Reply With Quote
 
kuyper
Guest
Posts: n/a
 
      08-23-2007
Mark Bluemel wrote:
....
> As you have given us very little context - platform, compiler, etc -
> unless someone here has seen exactly this, it's unlikely we can comment
> much more.


Platform: SGI Origin 300 running IRIX 6.5. The compiler is the SGI C
compiler distributed with that version of IRIX. Compiler options: -O2 -
mips4 -xansi -fullwarn. I first noticed this code when I changed -
xansi to -ansi, which apparantly turns off an SGI extension supporting
0-length arrays.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-23-2007
kuyper <(E-Mail Removed)> writes:
> Mark Bluemel wrote:
> ...
>> As you have given us very little context - platform, compiler, etc -
>> unless someone here has seen exactly this, it's unlikely we can comment
>> much more.

>
> Platform: SGI Origin 300 running IRIX 6.5. The compiler is the SGI C
> compiler distributed with that version of IRIX. Compiler options: -O2 -
> mips4 -xansi -fullwarn. I first noticed this code when I changed -
> xansi to -ansi, which apparantly turns off an SGI extension supporting
> 0-length arrays.


Can you find SGI's documentation for that extension?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
kuyper
Guest
Posts: n/a
 
      08-23-2007
Keith Thompson wrote:
> kuyper <(E-Mail Removed)> writes:

....
> > Platform: SGI Origin 300 running IRIX 6.5. The compiler is the SGI C
> > compiler distributed with that version of IRIX. Compiler options: -O2 -
> > mips4 -xansi -fullwarn. I first noticed this code when I changed -
> > xansi to -ansi, which apparantly turns off an SGI extension supporting
> > 0-length arrays.

>
> Can you find SGI's documentation for that extension?


No. I've downloaded their C manual, and wandered around their website,
without finding anything. I've found mentions of the fact that they
have extensions, but no comprehensive list of the extensions, and no
mention of this specific extension. However, when I use -xansi, the
compiler tolerates declaration of a zero-length array without comment,
and the program works as if the array has a non-zero length; when I
use -ansi, compilation fails. The distinction between those two
options is supposed to be that -xansi enables SGI-specific extensions
to ANSI C.

 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      08-23-2007
On Aug 24, 3:27 am, kuyper <(E-Mail Removed)> wrote:
> I've run across some rather peculiar code; here are the relevant lines
> that left me confused :
>
> unsigned char cr_file[384];
> unsigned char num_char[0];


Do these lines occur inside a structure definition?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
an oddball scary kind of thing you would think would never happen richard Computer Support 4 01-31-2010 06:34 PM
Assignment operator self-assignment check Chris C++ 34 09-26-2006 04:26 AM
Augument assignment versus regular assignment nagy Python 36 07-20-2006 07:24 PM
What would it take to change the behaviour of variable assignment? Daniel Nugent Ruby 10 10-30-2005 02:13 AM
Question about interference and Wireless Channel Assignment HOESan Wireless Networking 4 09-04-2004 08:36 PM



Advertisments