different struct sizes

Discussion in 'C Programming' started by Borked Pseudo Mailed, Nov 6, 2006.

  1. I have this weird problem with the JPEG library that I am using. There
    is a function that is being called and one of the parameters being
    passed is the length of a structure. Inside this function, the length
    of the structure being passed is compared to the length of the same
    structure calculated inside the function. Now because these values do
    not match, the program exits.

    ======================

    This is the prototype for this function:

    jpeg_CreateDecompress((cinfo), JPEG_LIB_VERSION, q(size_t) sizeof(struct
    jpeg_decompress_struct));

    ======================

    Now this is a portion of this function's code:

    GLOBAL(void) jpeg_CreateDecompress (j_decompress_ptr cinfo, int version,
    size_t structsize)
    {
    int i;

    /* Guard against version mismatches between library and caller. */
    cinfo->mem = NULL; /* so jpeg_destroy knows mem mgr not called
    */
    if (version != JPEG_LIB_VERSION)
    ERREXIT2(cinfo, JERR_BAD_LIB_VERSION, JPEG_LIB_VERSION, version);
    if (structsize != SIZEOF(struct jpeg_decompress_struct))
    ERREXIT2(cinfo, JERR_BAD_STRUCT_SIZE,(int) SIZEOF(struct
    jpeg_decompress_struct), (int) structsize);

    ======================

    This is the error produced by this function:

    JPEG parameter struct mismatch: library thinks size is 452, caller
    expects 404

    ======================

    Would anyone have any idea as to why something like this would happen?

    Thanks

    Reply
     
    Borked Pseudo Mailed, Nov 6, 2006
    #1
    1. Advertisements

  2. Borked Pseudo Mailed

    Ian Collins Guest

    Odd looking prototype...
    What is SIZEOF()?
    Have the library and your code been compiled with the same compiler and
    if used, alignment options?
     
    Ian Collins, Nov 6, 2006
    #2
    1. Advertisements

  3. Borked Pseudo Mailed

    Nagaraj L Guest

    You are using a library compiled on a platform other than what you are
    using. You require libraries compiled for your platform (Same Hardware
    and compiler options).

    Certain platforms use 4 bytes memory for "char" and "short int"
    variables. when you use 1 byte for char and 2 byte for short int on
    your platform, this kind of problems are reported.

    Regards,
    Nagaraj L
     
    Nagaraj L, Nov 6, 2006
    #3
  4. Any platform that uses 4 bytes of memory for "char" variables is
    non-conforming. sizeof(char) is 1.
     
    Christopher Benson-Manica, Nov 6, 2006
    #4
  5. Borked Pseudo Mailed

    Simias Guest

    sizeof(char) is 1 by definition, that doesn't mean that it's one byte
     
    Simias, Nov 6, 2006
    #5
  6. Borked Pseudo Mailed

    Richard Bos Guest

    It does in an ISO C context. One byte need not be one octet, however,
    and historically it hasn't always been.

    Richard
     
    Richard Bos, Nov 6, 2006
    #6
  7. Borked Pseudo Mailed

    CBFalconer Guest

    Nagarajs terminology is flawed. He could have written 'octets' in
    place of bytes. This is quite likely on some conforming systems.
     
    CBFalconer, Nov 6, 2006
    #7
  8. Yes, it certainly does; that's the C standar's definition of "byte".
     
    Keith Thompson, Nov 6, 2006
    #8
  9. Unfortunately any platform will have its own definition of byte, and
    though these coincide 99.9% of the time, the difficult cases will be
    the ones where it doesn't. The fact that something is true of C's
    definition of byte is not very useful when the issue is how it maps
    onto the implementation - you can't expect every word to be used with
    C's definition in that context.

    -- Richard
     
    Richard Tobin, Nov 6, 2006
    #9
  10. In this newsgroup, I can and I do expect words defined in the C
    standard to be used in accordance with the way the C standard defines
    them. Anyone using the word "byte" here in some other sense needs to
    say so.

    The statement was:

    sizeof(char) is 1 by definition, that doesn't mean that it's one byte

    If the poster had said:

    sizeof(char) is 1 by definition, that doesn't mean that it's one byte
    (as a particular platform defines the word "byte")

    I would have had no objection.
     
    Keith Thompson, Nov 7, 2006
    #10
  11. Borked Pseudo Mailed

    jacob navia Guest

    Important distinction. When I ported lcc-win32 to a DSP, each
    character took two bytes (16 bits) because the machine could not
    address odd bytes. Still, sizeof(char) was 1 of course.

    In that environment sizeof(char) == sizeof(short) == sizeof(int).
    Only longs were 32 bits.
     
    jacob navia, Nov 7, 2006
    #11
  12. Yes, it's an important distinction, and you're blurring it.

    Each character took *one* byte (16 bits). One byte happened to be two
    octets.
    Perfectly legal, of course. It could cause some interesting problems
    with stdio, since it's difficult to distinguish between EOF and a
    character that happens to have the same value. But a DSP would
    presumably have a freestanding implementation, so stdio support isn't
    required.
     
    Keith Thompson, Nov 7, 2006
    #12
  13. Borked Pseudo Mailed

    Nagaraj L Guest

    Note: It should be referred as octet(s).

    A character is 1 byte all the time. But it takes 2 octets example on -
    Intel, ST10 platforms and many other platforms. It is decided by the
    processor.

    Certain processors require even addressing for address alignment. Some
    processors require x4 alignments ( Here 1 character takes 1 byte but in
    memory it takes 4 octets). The 3 octets are not used. char still uses 8
    bits or 1 byte only.
     
    Nagaraj L, Nov 7, 2006
    #13
  14. A C implementation *must* allow char objects to be stored at odd byte
    addresses. It can choose to align all single declared char objects,
    or even char struct members, at even addresses if that makes access
    easier or faster, but there can be no padding between array elements:

    char arr[2];
    /* either arr[0] or arr[1] is at an odd byte address */

    If the hardware doesn't allow this (or makes it too expensive), then
    the implementation can make bytes bigger than 8 bits.
     
    Keith Thompson, Nov 7, 2006
    #14
  15. Keith Thompson said:
    And perfectly common in the DSP universe.
    Even if stdio support is provided, I don't think it actually matters very
    much about the EOF issue, in practical terms. Yes, 0xFFFF (or 0xFFFFFFFF,
    or however many bits you're dealing with) can be seen as either EOF or a
    character value, but (a) there's no problem when CHAR_BIT < 16, and (b)
    when CHAR_BIT /is/ 16 or higher, the chances of real world data containing
    a genuine character with the maximum possible value are pretty low. You'd
    have to work pretty hard to find a counter-example, I think.
     
    Richard Heathfield, Nov 7, 2006
    #15
  16. Borked Pseudo Mailed

    Guest Guest

    I don't think it's hard at all. Just be sure not to limit your search
    to text files.
     
    Guest, Nov 7, 2006
    #16
  17. Harald van D?k said:
    Okay, let me put that another way - if you want to *avoid* the problem, you
    probably can do so without too much hassle by designing your system
    accordingly. If you are seeking out the problem, however, then of course
    you're going to find it. Humans are good at finding problems. :)
     
    Richard Heathfield, Nov 7, 2006
    #17
  18. Borked Pseudo Mailed

    Guest Guest

    Oh, I actually mean you're very likely to run into it by accident
    unless you specifically avoid the issue (which I can agree may not be
    hard). At the very least, if a system allows you to upload code (which
    does not usually happen with DSPs (I think), but does happen with other
    embedded systems), and the code checks for EOF, the code is extremely
    likely to contain EOF itself.
     
    Guest, Nov 7, 2006
    #18
  19. Borked Pseudo Mailed

    Richard Bos Guest

    If it is known that a program's input is not text but (possibly) binary,
    the wise programmer doesn't use fgetc() in the first place. He uses
    fread(), which doesn't have this problem even when CHAR_MAX == INT_MAX.
    Similar things can be said about <ctype.h>, whose functions are
    typically only used on text, not on unknown data that could be either
    text or binary.

    Richard
     
    Richard Bos, Nov 7, 2006
    #19
  20. Borked Pseudo Mailed

    Guest Guest

    I can agree that that's (almost) always a better idea.
    Well yeah, but the is* functions are never (counterexamples are
    welcome) useful for binary data, but fgetc() is merely a less than
    optimal solution.
     
    Guest, Nov 7, 2006
    #20
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.