different struct sizes

[Borked Pseudo Mailed]

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

 

[Ian Collins]

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));

Odd looking prototype...

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

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);

What is SIZEOF()?

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

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?

Have the library and your code been compiled with the same compiler and
if used, alignment options?

 

[Nagaraj L]

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

 

[Christopher Benson-Manica]

Certain platforms use 4 bytes memory for "char" and "short int"

Any platform that uses 4 bytes of memory for "char" variables is
non-conforming. sizeof(char) is 1.

 

[Simias]

Any platform that uses 4 bytes of memory for "char" variables is
non-conforming. sizeof(char) is 1.

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

 

[Richard Bos]

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

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

Richard

 

[CBFalconer]

Any platform that uses 4 bytes of memory for "char" variables is
non-conforming. sizeof(char) is 1.

Nagarajs terminology is flawed. He could have written 'octets' in
place of bytes. This is quite likely on some conforming systems.

 

[Keith Thompson]

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

Yes, it certainly does; that's the C standar's definition of "byte".

 

[Richard Tobin]

Yes, it certainly does; that's the C standar's definition of "byte".

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

 

[Keith Thompson]

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.

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.

 

[jacob navia]

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.

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.

 

[Keith Thompson]

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.

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.

In that environment sizeof(char) == sizeof(short) == sizeof(int).
Only longs were 32 bits.

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.

 

[Nagaraj L]

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.

 

[Keith Thompson]

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.

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.

 

[Richard Heathfield]

Keith Thompson said:

Perfectly legal, of course.

And perfectly common in the DSP universe.

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.

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.

 

[Guest]

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.

I don't think it's hard at all. Just be sure not to limit your search
to text files.

 

[Richard Heathfield]

Harald van D?k said:

I don't think it's hard at all. Just be sure not to limit your search
to text files.

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.

 

[Guest]

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.

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.

 

[Richard Bos]

I don't think it's hard at all. Just be sure not to limit your search
to text files.

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

 

[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.

I can agree that that's (almost) always a better idea.

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.

Well yeah, but the is* functions are never (counterexamples are
welcome) useful for binary data, but fgetc() is merely a less than
optimal solution.