different struct sizes

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 wrote:

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?

--
Ian Collins.

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

On Nov 6, 6:58 am, Borked Pseudo Mailed <nob...@pseudo.borked.net>
wrote:

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

Nagaraj L <nagarajl@gmail.comwrote:

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.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

Christopher Benson-Manica <ataru@otaku.freeshell.orgwrites:

Nagaraj L <nagarajl@gmail.comwrote:
>

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

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

--
Simias

Simias <nobody@nowhere.comwrote:

Christopher Benson-Manica <ataru@otaku.freeshell.orgwrites:
>

Nagaraj L <nagarajl@gmail.comwrote:

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.

>
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

Christopher Benson-Manica wrote:

Nagaraj L <nagarajl@gmail.comwrote:
>

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

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

Simias <nobody@nowhere.comwrites:

Christopher Benson-Manica <ataru@otaku.freeshell.orgwrites:

>Nagaraj L <nagarajl@gmail.comwrote:

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

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

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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.

In article <lny7qoi6j1.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.orgwrote:

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

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

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <lny7qoi6j1.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.orgwrote:

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

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

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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.

Keith Thompson wrote:

richard@cogsci.ed.ac.uk (Richard Tobin) writes:
>

>>In article <lny7qoi6j1.fsf@nuthaus.mib.org>,
>>Keith Thompson <kst-u@mib.orgwrote:
>>

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

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

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 <jacob@jacob.remcomp.frwrites:

Keith Thompson wrote:

>richard@cogsci.ed.ac.uk (Richard Tobin) writes:
>>

>>>In article <lny7qoi6j1.fsf@nuthaus.mib.org>,
>>>Keith Thompson <kst-u@mib.orgwrote:
>>>
>>>>>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".
>>>
>>>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.

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

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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.

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" <nagarajl@gmail.comwrites:

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.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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.

Keith Thompson said:

jacob navia <jacob@jacob.remcomp.frwrites:

<snip>

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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Richard Heathfield wrote:

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.

Harald van D?k said:

Richard Heathfield wrote:

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

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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Richard Heathfield wrote:

Harald van D?k said:

Richard Heathfield wrote:

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.

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

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <truedfx@gmail.comwrote:

Richard Heathfield wrote:

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.

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 wrote:

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <truedfx@gmail.comwrote:

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.

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.

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <truedfx@gmail.comwrote:

Richard Bos wrote:

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,

I can think of only one reason: a strings-like utility program. That's
system-level enough not to make this a problem.

Richard

2006-11-07 <45505f08.626166@news.xs4all.nl>,
Richard Bos wrote:

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <truedfx@gmail.comwrote:
>

>Richard Bos wrote:

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,

>
I can think of only one reason: a strings-like utility program. That's
system-level enough not to make this a problem.

How is strings system-level?

#define N 4
main(int argc, char **argv) {
int c;
int i=0;
char buf[N];
FILE *myfile = ...;
while(c = getc(file) != EOF) {
if(isprint(c) || isspace(c))
if(i<N) {
buf[i++]=c;
if(i==N) { i++; fwrite(buf,1,N,stdout); }
} else {
putchar(c);
}
}
else {
if(i==N+1) {
putchar('\n');
i=0;
}
}
}
putchar('\n');
}

In article <lnbqnki0qr.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.orgwrote:

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

Well, you're often going to be disappointed.

The newsgroup isn't the *only* context determining how a word should
be interpreted. Usenet isn't a standards document, it's a
conversation.

>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

And he said it in the context of a up-thread statement

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

Why not start by assuming that the person is talking sense? (Of
course, you may have to change your assumption later.) Since "byte"
corresponds to "char" in C standards-speak, it would make no sense for
him to say "that doesn't mean that it's one byte" if he had meant the
C-standards-speak usage of "byte". Assuming that he is talking sense
removes the ambiguity, and your response therefore seems excessively
pedantic.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

In article <3N6dnegyD9Bpuc3YRVnyjQ@bt.com>,
Richard Heathfield <invalid@invalid.invalidwrote:

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

And anyone designing such a character set today would be nuts.
Unicode for example makes 0xFFFF be an explicit non-character,
because of its likely use for purposes such as EOF.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Richard Tobin wrote:

>
In article <lnbqnki0qr.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.orgwrote:
>

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.

>
Well, you're often going to be disappointed.
>
The newsgroup isn't the *only* context determining how a word should
be interpreted. Usenet isn't a standards document, it's a
conversation.
>

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

>
And he said it in the context of a up-thread statement
>
Certain platforms use 4 bytes memory for "char" and "short int"
variables
>
Why not start by assuming that the person is talking sense?

Because it makes no sense.

N869
6.5.3.4 The sizeof operator
The sizeof operator yields the size (in bytes) of its operand

--
pete

different struct sizes

Post your reply

Question stats

Most Active

Most Questions Answered

Top Questions

Latest Questions

Similar topics

More