memcpy() where assignment would do?

[kuyper]

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.

[Jensen Somers]

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.

[Mark Bluemel]

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.

[kuyper]

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.

[Old Wolf]

On Aug 24, 3:27 am, kuyper <[e-mail]:

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?

[kuyper]

Old Wolf wrote:

On Aug 24, 3:27 am, kuyper <[e-mail]:

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?

No - they occur at block scope.

[Peter J. Holzer]

On 2007-08-24 12:01, kuyper <ku****@wizard.netwrote:

Old Wolf wrote:

>On Aug 24, 3:27 am, kuyper <[e-mail]:

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?

No - they occur at block scope.

That's strange. Before C89 many compilers accepted zero-sized arrays and
it was a common idiom to define a structure like this:

struct foo {
size_t size; /* more likely int a the time */
short whatever;
double data[0];
}

and use it like this:

struct foo *p = malloc(sizeof struct foo + sizeof double * nelems);

p->size = nelems;
p->whatever = 42;
for (i = 0; i < nelems; i++) {
p->data[i] = get_some_data();
}

/* do some more processing */

free(p);

data didn't actually use any space in the struct, but enforced proper
alignment and padding, so the single malloc would allocate the exact
amount of memory needed.

C89 didn't standardize zero-sized arrays (presumably because they
didn't fit with the "pointer arithmetic only defined within an object"
model) and subsequently people stopped using that idiom and (more)
compilers started to reject it.

I don't know what possible use a zero-sized array could have as an
automatic variable. If it's really zero-sized it's completely useless,
and if it isn't it must be some fixed size (at least if it is used with
memset as you showed - if it was used with ordinary indexes I could
imagine some compiler magic implementing a dynamic array[0]), and if it's
some fixed size, why not use that?

hp

[0] Yes, there could of course be some other compiler magic which calls
__builtin_dynamic_array_memset if memset is used on zero-sized
array and __builtin_normal_memset otherwise.

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[CBFalconer]

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

[kuyper]

CBFalconer wrote:

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.

Yes, of course. The size of that array doesn't confuse me. The bizarre
thing is the way it was used.

unsigned char num_char[0];

This is illegal. 0 size arrays cannot be declared.

Well, of course. Nonetheless, it was declared, and it does compile,
and it does work, apparently as a result of using a compiler flag
which enables SGI-specific extensions. A (small) part of my question
is "why was it declared with a length of 0?" The bigger part is given
in the Subject: header.

[Keith Thompson]

kuyper <ku****@wizard.netwrites:

CBFalconer wrote:

[...]

>This is illegal. 0 size arrays cannot be declared.

Well, of course. Nonetheless, it was declared, and it does compile,
and it does work, apparently as a result of using a compiler flag
which enables SGI-specific extensions. A (small) part of my question
is "why was it declared with a length of 0?" The bigger part is given
in the Subject: header.

You said elsethread that this appears to be an SGI-specific extension.
Have you tried one of the comp.sys.sgi.* newsgroups? Or can you
contact SGI customer support?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"

[kuyper]

Keith Thompson wrote:

kuyper <ku****@wizard.netwrites:

CBFalconer wrote:

[...]

This is illegal. 0 size arrays cannot be declared.

Well, of course. Nonetheless, it was declared, and it does compile,
and it does work, apparently as a result of using a compiler flag
which enables SGI-specific extensions. A (small) part of my question
is "why was it declared with a length of 0?" The bigger part is given
in the Subject: header.

You said elsethread that this appears to be an SGI-specific extension.
Have you tried one of the comp.sys.sgi.* newsgroups? Or can you
contact SGI customer support?

No, I haven't. While some people have suggested otherwise, I don't
think that the 0-sized array is related to the peculiar memcpy() calls
- the proposed connections are all pretty implausible to me. Since
it's the memcpy() calls that I'm mainly confused by, I haven't
followed upon on the SGI extensions angle. Of course, the memcpy()
seems pretty implausible too; but there it is. Maybe I should check
out SGI sources, though at this time I'm more inclined to simply drop
it.

[Richard Tobin]

In article <11*********************@z24g2000prh.googlegroups. com>,
kuyper <ku****@wizard.netwrote:

>I've run across some rather peculiar code;

Is there any possibility that this code was originally machine-generated,
or results from macro-expansion of something more plausible?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.