memcpy() where assignment would do?

Discussion in 'C Programming' started by kuyper, Aug 23, 2007.

  1. kuyper

    kuyper Guest

    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.
    kuyper, Aug 23, 2007
    #1
    1. Advertising

  2. 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.
    Jensen Somers, Aug 23, 2007
    #2
    1. Advertising

  3. kuyper

    Eric Sosman Guest

    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?

    --
    Eric Sosman, Aug 23, 2007
    #3
  4. kuyper

    Mark Bluemel Guest

    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, Aug 23, 2007
    #4
  5. kuyper

    CBFalconer Guest

    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
    CBFalconer, Aug 23, 2007
    #5
  6. kuyper

    kuyper Guest

    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.
    kuyper, Aug 23, 2007
    #6
  7. kuyper

    kuyper Guest

    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, Aug 23, 2007
    #7
  8. 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) <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, Aug 23, 2007
    #8
  9. kuyper

    kuyper Guest

    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.
    kuyper, Aug 23, 2007
    #9
  10. kuyper

    Old Wolf Guest

    On Aug 24, 3:27 am, 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];


    Do these lines occur inside a structure definition?
    Old Wolf, Aug 23, 2007
    #10
  11. kuyper

    kuyper Guest

    Old Wolf wrote:
    > On Aug 24, 3:27 am, 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];

    >
    > Do these lines occur inside a structure definition?


    No - they occur at block scope.
    kuyper, Aug 24, 2007
    #11
  12. On 2007-08-24 12:01, kuyper <> wrote:
    > Old Wolf wrote:
    >> On Aug 24, 3:27 am, 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];

    >>
    >> 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 = 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.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Aug 24, 2007
    #12
  13. kuyper

    Guest

    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];
    >
    >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.

    Neil


    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    , Aug 25, 2007
    #13
  14. kuyper

    kuyper Guest

    wrote:
    > 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];
    > >
    > >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.
    kuyper, Aug 25, 2007
    #14
  15. kuyper

    kuyper Guest

    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.
    kuyper, Aug 25, 2007
    #15
  16. kuyper <> writes:
    > 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) <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, Aug 25, 2007
    #16
  17. kuyper

    kuyper Guest

    Keith Thompson wrote:
    > kuyper <> writes:
    > > 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.
    kuyper, Aug 25, 2007
    #17
  18. In article <>,
    kuyper <> wrote:

    >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.
    Richard Tobin, Aug 26, 2007
    #18
  19. kuyper

    kuyper Guest

    Richard Tobin wrote:
    > In article <>,
    > kuyper <> wrote:
    >
    > >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?


    Not likely. We don't use much machine-generated code in our project. I
    believe that this program was created by hand, most likely by
    modification of an existing program by the same author intended to
    handle the same data set in a different fashion; but I have no idea
    which program that was, nor where it might be found. Literally
    inheriting responsibility for a program can be very difficult,
    partticularly when, as in this case, the late author was not strong on
    documentation, either internal or external.
    kuyper, Aug 27, 2007
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. nagy
    Replies:
    36
    Views:
    996
    Terry Reedy
    Jul 20, 2006
  2. gsyoon
    Replies:
    4
    Views:
    387
    gsyoon
    Aug 11, 2005
  3. aiooua

    simple assignment of structs vs. memcpy

    aiooua, Mar 10, 2007, in forum: C Programming
    Replies:
    5
    Views:
    467
    aiooua
    Mar 10, 2007
  4. , India

    structure assignment vs memcpy

    , India, Mar 10, 2007, in forum: C Programming
    Replies:
    2
    Views:
    1,176
    Richard Tobin
    Mar 10, 2007
  5. Daniel Nugent
    Replies:
    10
    Views:
    179
    Phil Tomson
    Oct 30, 2005
Loading...

Share This Page