«

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.

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.

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?

--

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.

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

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.

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.

kuyper <> 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) kst- <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"

Keith Thompson wrote:
> kuyper <> 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.

On Aug 24, 3:27 am, kuyper <kuy...@wizard.net> 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?