memcpy（）在哪里分配？ [英] memcpy() where assignment would do?
问题描述
我遇到了一些相当特殊的代码;这里有相关的行
让我感到困惑：
unsigned char cr_file [384];
unsigned char num_char [0 ];
注意：这个声明实际上适用于我们的编译器，并且看起来
相当于给出长度为1.开发人员插入
编译器选项进入make文件关闭相关警告
消息。遗憾的是，这不是代码中最令人困惑的部分。这个
是一个令人困惑的部分的例子：
num_char [0] = 1;
memcpy（& cr_file [ 147]，num_char，1）;
num_char仅以这种方式使用;调用
memcpy（）之后的值与程序的行为无关。我可能会错过某些东西，但在我看来这个代码是因为
完全相当于
cr_file [147 ] = 1;
实际上，我希望有些编译器会为这两种编写方式生成相同的
代码。
我错过了什么吗？如果没有，有人至少可以建议开发人员为什么要编写这样奇怪的代码？b
合理的原因？我不能问开发人员，他最近去世了，这就是我对这段代码负责的问题。
On Thu，2007年8月23日08:27:34 -0700，kuyper写道：
< blockquote class =post_quotes>
我遇到了一些相当特殊的代码;这里有相关的行
让我感到困惑：
unsigned char cr_file [384];
unsigned char num_char [0 ]。
IIRC，这是GCC扩展。当使用
Microsoft Visual C编译器（它仍然使用ISO89
标准的一些分支）时，我遇到了这个问题。经过进一步调查后发现这似乎是一个
扩展名，并且在编译--pedantic时会抛出警告/错误。
Jensen。
kuyper写道：
我遇到了一些相当特殊的代码;这里有相关的行
让我感到困惑：
unsigned char cr_file [384];
unsigned char num_char [0 ];
注意：这个声明实际上适用于我们的编译器，并且看起来
相当于给出长度为1.开发人员插入
编译器选项进入make文件关闭相关警告
消息。遗憾的是，这不是代码中最令人困惑的部分。这个
是一个令人困惑的部分的例子：
num_char [0] = 1;
memcpy（& cr_file [ 147]，num_char，1）;
num_char仅以这种方式使用;调用
memcpy（）之后的值与程序的行为无关。我可能会错过某些东西，但在我看来这个代码是因为
完全相当于
cr_file [147 ] = 1;
实际上，我希望有些编译器会为这两种编写方式生成相同的
代码。
我会倾向于调查我的编译器为这些构造生成的每个元素，并查看差异可能意味着什么。 ..
因为你给了我们很少的上下文 - 平台，编译器等 -
除非有人在这里看到了这个，它不太可能我们可以评论
更多。
Mark Bluemel写道：
....
< blockquote class =post_quotes>
因为你给了我们很少的上下文 - 平台，编译器等 -
除非有人在这里看到了这个，我们不太可能评论
更多。
平台：SGI Origin 300运行IRIX 6.5。编译器是与该版本的IRIX一起分发的SGI C
编译器。编译器选项：-O2 -
mips4 -xansi -fullwarn。当我改变时，我第一次注意到这个代码 -
xansi到-ansi，它显然关闭了支持
0长度阵列的SGI扩展。
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: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.
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.
这篇关于memcpy（）在哪里分配？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
