Re: memcpy() where assignment would do?

neildfergu...@xxxxxxxxxxx wrote:
On Thu, 23 Aug 2007 08:27:34 -0700, kuyper <kuyper@xxxxxxxxxx> 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.

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.

Here's a very off-topic possibility: the variables are defined as they are in
order to appear in particular segments of the linker's memory map, with
particular symbolic identification, so that the memory's addresses can be
associated with particular hardware I/O operations.

Ingenious possibility, but unfortunately not a plausible explanation
for this program. It's only purpose is breaking up a large partitioned
data set into several smaller files, which is non-trivial only because
the records are variable length, the files have to be split at the
boundary between two records, and each output file requires a seperate
header. cr_file is the array containing that header. It's not a very
complicated program. As a result, this wierd way of filling in the
headers adds significantly and unnecessarily to the total complexity.

For now, I'm assuming that he didn't have a valid reason for writing
the code this way. I suspect that I'll probably never learn what the
invalid reason was that motivated him to do so.

.

Relevant Pages

  • Re: SendInput wont compile
    ... The reason is "precompiled headers". ... of a modern Platform SDK, a new MFC, a real C++ compiler, and other features compensate ... Even the most casual inspection of the header file shows that this is ...
    (microsoft.public.vc.mfc)
  • Re: What would cause static function double round(double,int) declared but not defined
    ... Did you declare roundas a static member function? ... It's not immediately obvious to me what is confusing the compiler. ... reason. ...
    (microsoft.public.vc.atl)
  • Re: Is this acceptable (i.e., compliant) code?
    ... Is there some actual reason vs. just a style preference? ... >> use the parens, they were more likely to leave out the parens on ... >> create a level of consistency that is less confusing for them at ... compiler when compiling the following two functions (use cut and paste, ...
    (comp.lang.c)
  • Re: Header Files and Interfaces Yet Again
    ... compiler is not allowed to read them. ... illustrate the difference of header file and fake header. ... fake headers can not serve as sufficient information to the ... > something but it appears to me the Standard Library is not designed ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... >> I will observe that many Java IDEs do this rather successfully. ... > Look, if a tool author is willing to fully parse the underlying language, ... > compiler version. ... mentions a header file is in the C compatability appendix. ...
    (comp.lang.cpp)