why the size of FILE structure instance is 216 bytes in 64 bit os and 148 Bytes in 32 bit os?
If I print the size of FILE or FILE instance then the results are 216 Bytes in
64 Bit system and 148 Bytes in 32 Bit system (OS : Ubuntu 16.04 , compile :GCC)
printf("size : %zu",sizeof(FILE));
OR
FILE *fp;
printf("size : %zu",sizeof(*fp));
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
c file data-structures file-handling
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
|
show 3 more comments
If I print the size of FILE or FILE instance then the results are 216 Bytes in
64 Bit system and 148 Bytes in 32 Bit system (OS : Ubuntu 16.04 , compile :GCC)
printf("size : %zu",sizeof(FILE));
OR
FILE *fp;
printf("size : %zu",sizeof(*fp));
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
c file data-structures file-handling
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
7
The implementation's internal format forFILEnotwithstanding (you shoudn't have to care) why are you using%dfor printing asize_texpression? That should be%zu. And if the members are "mostly pointers" consider that each pointer in a 32bit vs 64bit representation will literally double in size going from the former to the latter.
– WhozCraig
Nov 26 '18 at 7:11
7
It most certainly does play an important role. Using the wrong format specifier is basically lying toprintf, and invokes undefined behavior if/when the arguments are not of the precise type expected by the corresponding specifier. There's enough UB in the coding world; no reason to add to it with trivialities, especially when they're simple enough to just do the correct thing in the first place. Ex: ifsize_tandintare 64 and 32 bit respectively on your architecture (most 64bit arches are such), then you'd be shoving a 64bit value to a function expecting a 32bit value.
– WhozCraig
Nov 26 '18 at 7:21
1
I checked with %zu and updated the same , thank you .
– new_learner
Nov 26 '18 at 7:24
1
BTW, in practice, aFILEtakes much more resources: some buffer (kilobytes) and a file descriptor (resource known to the operating system kernel)
– Basile Starynkevitch
Nov 26 '18 at 7:53
1
Which values did you expect and why?
– Gerhardh
Nov 26 '18 at 9:04
|
show 3 more comments
If I print the size of FILE or FILE instance then the results are 216 Bytes in
64 Bit system and 148 Bytes in 32 Bit system (OS : Ubuntu 16.04 , compile :GCC)
printf("size : %zu",sizeof(FILE));
OR
FILE *fp;
printf("size : %zu",sizeof(*fp));
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
c file data-structures file-handling
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
If I print the size of FILE or FILE instance then the results are 216 Bytes in
64 Bit system and 148 Bytes in 32 Bit system (OS : Ubuntu 16.04 , compile :GCC)
printf("size : %zu",sizeof(FILE));
OR
FILE *fp;
printf("size : %zu",sizeof(*fp));
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
c file data-structures file-handling
c file data-structures file-handling
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
edited Nov 26 '18 at 7:23
new_learner
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
asked Nov 26 '18 at 7:05
new_learnernew_learner
11410
11410
7
The implementation's internal format forFILEnotwithstanding (you shoudn't have to care) why are you using%dfor printing asize_texpression? That should be%zu. And if the members are "mostly pointers" consider that each pointer in a 32bit vs 64bit representation will literally double in size going from the former to the latter.
– WhozCraig
Nov 26 '18 at 7:11
7
It most certainly does play an important role. Using the wrong format specifier is basically lying toprintf, and invokes undefined behavior if/when the arguments are not of the precise type expected by the corresponding specifier. There's enough UB in the coding world; no reason to add to it with trivialities, especially when they're simple enough to just do the correct thing in the first place. Ex: ifsize_tandintare 64 and 32 bit respectively on your architecture (most 64bit arches are such), then you'd be shoving a 64bit value to a function expecting a 32bit value.
– WhozCraig
Nov 26 '18 at 7:21
1
I checked with %zu and updated the same , thank you .
– new_learner
Nov 26 '18 at 7:24
1
BTW, in practice, aFILEtakes much more resources: some buffer (kilobytes) and a file descriptor (resource known to the operating system kernel)
– Basile Starynkevitch
Nov 26 '18 at 7:53
1
Which values did you expect and why?
– Gerhardh
Nov 26 '18 at 9:04
|
show 3 more comments
7
The implementation's internal format forFILEnotwithstanding (you shoudn't have to care) why are you using%dfor printing asize_texpression? That should be%zu. And if the members are "mostly pointers" consider that each pointer in a 32bit vs 64bit representation will literally double in size going from the former to the latter.
– WhozCraig
Nov 26 '18 at 7:11
7
It most certainly does play an important role. Using the wrong format specifier is basically lying toprintf, and invokes undefined behavior if/when the arguments are not of the precise type expected by the corresponding specifier. There's enough UB in the coding world; no reason to add to it with trivialities, especially when they're simple enough to just do the correct thing in the first place. Ex: ifsize_tandintare 64 and 32 bit respectively on your architecture (most 64bit arches are such), then you'd be shoving a 64bit value to a function expecting a 32bit value.
– WhozCraig
Nov 26 '18 at 7:21
1
I checked with %zu and updated the same , thank you .
– new_learner
Nov 26 '18 at 7:24
1
BTW, in practice, aFILEtakes much more resources: some buffer (kilobytes) and a file descriptor (resource known to the operating system kernel)
– Basile Starynkevitch
Nov 26 '18 at 7:53
1
Which values did you expect and why?
– Gerhardh
Nov 26 '18 at 9:04
7
7
The implementation's internal format for
FILE notwithstanding (you shoudn't have to care) why are you using %d for printing a size_t expression? That should be %zu. And if the members are "mostly pointers" consider that each pointer in a 32bit vs 64bit representation will literally double in size going from the former to the latter.– WhozCraig
Nov 26 '18 at 7:11
The implementation's internal format for
FILE notwithstanding (you shoudn't have to care) why are you using %d for printing a size_t expression? That should be %zu. And if the members are "mostly pointers" consider that each pointer in a 32bit vs 64bit representation will literally double in size going from the former to the latter.– WhozCraig
Nov 26 '18 at 7:11
7
7
It most certainly does play an important role. Using the wrong format specifier is basically lying to
printf, and invokes undefined behavior if/when the arguments are not of the precise type expected by the corresponding specifier. There's enough UB in the coding world; no reason to add to it with trivialities, especially when they're simple enough to just do the correct thing in the first place. Ex: if size_t and int are 64 and 32 bit respectively on your architecture (most 64bit arches are such), then you'd be shoving a 64bit value to a function expecting a 32bit value.– WhozCraig
Nov 26 '18 at 7:21
It most certainly does play an important role. Using the wrong format specifier is basically lying to
printf, and invokes undefined behavior if/when the arguments are not of the precise type expected by the corresponding specifier. There's enough UB in the coding world; no reason to add to it with trivialities, especially when they're simple enough to just do the correct thing in the first place. Ex: if size_t and int are 64 and 32 bit respectively on your architecture (most 64bit arches are such), then you'd be shoving a 64bit value to a function expecting a 32bit value.– WhozCraig
Nov 26 '18 at 7:21
1
1
I checked with %zu and updated the same , thank you .
– new_learner
Nov 26 '18 at 7:24
I checked with %zu and updated the same , thank you .
– new_learner
Nov 26 '18 at 7:24
1
1
BTW, in practice, a
FILE takes much more resources: some buffer (kilobytes) and a file descriptor (resource known to the operating system kernel)– Basile Starynkevitch
Nov 26 '18 at 7:53
BTW, in practice, a
FILE takes much more resources: some buffer (kilobytes) and a file descriptor (resource known to the operating system kernel)– Basile Starynkevitch
Nov 26 '18 at 7:53
1
1
Which values did you expect and why?
– Gerhardh
Nov 26 '18 at 9:04
Which values did you expect and why?
– Gerhardh
Nov 26 '18 at 9:04
|
show 3 more comments
2 Answers
2
active
oldest
votes
the results are 216 Bytes in 64 Bit system and 148 Bytes in 32 Bit system
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
The contents of FILE structure are implementation-specific (which means they are different in different platforms).
On a 32-bit system, the size of a pointer is usually 4 bytes and on a 64-bit system the size of a pointer is usually 8 bytes.
So the difference in the size you see (216 - 148 = 68) can be easily accounted for. (From what I remember this structure has about 15 pointers in Ubuntu GCC).
And apart from pointers the sizes of other types like int, long (which can be part of FILE structure) etc can differ from 32 and 64 bits systems.
Including @MatteoItalia comments below:
In particular, using this definition from glibc (and _IO_USE_OLD_IO_FILE undefined) I do get 148 bytes (with 4-byte int, pointers, size_t and __off_t).
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as 15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t) is 40 on 32 bit, but 24 on 64 bit)
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
thank you , I got your point about difference between 32bit and 64 bit system . Now can you please explain why the size is 148 for 32 bit os.
– new_learner
Nov 26 '18 at 7:26
1
@new_learner because there's 148 byte of data in there? It's really implementation-specific, depending from your system headers; dig them up from your compiler includes directory, sum up the fields sizes (taking padding in account) and you'll see that it'll add up to 148.
– Matteo Italia
Nov 26 '18 at 7:28
1
In particular, using this definition from glibc (and_IO_USE_OLD_IO_FILEundefined) I do get 148 bytes (with 4-byteint, pointers,size_tand__off_t).
– Matteo Italia
Nov 26 '18 at 7:35
1
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)is 40 on 32 bit, but 24 on 64 bit).
– Matteo Italia
Nov 26 '18 at 7:40
1
@MatteoItalia: Can I include your comments in the answer?
– P.W
Nov 26 '18 at 7:42
|
show 2 more comments
The contents and size of the FILE structure is entirely specific to the implementation. it happens to be 216 bytes on your OS in 64-bit mode and 148 in 32-bit mode. The difference could come from the differing sizes of some of the members of this structure between 32-bit and 64-bit mode: pointers are larger, as well as size_t and file positions, it really depends on how the C library handles the standard streams.
Note that some extra information might be stored outside the structure... in any case you cannot save a FILE to a local variable and restore it safely.
Note that FILE could also be an incomplete type: a typedef for a pointer to a structure whose definition is absent, in which case sizeof(FILE) would cause a compilation error. The main reason to put the definition in the <stdio.h> header is to allow macros to access members directly. Take a look into your <stdio.h> file and look for other implementations in open source, such as the newlib or the glibc.
Furthermore, the C Standard does not mandate that FILE be a typedef for a structure: it might not be a structure, it could be defined as an int.
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
@Note that FILE might not be a structure at all. It could be defined as an int . FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h)
– new_learner
Nov 26 '18 at 9:06
2
@new_learner FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h) That's true only for the one implementation you looked at. There are others - many others.
– Andrew Henle
Nov 26 '18 at 10:12
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53476148%2fwhy-the-size-of-file-structure-instance-is-216-bytes-in-64-bit-os-and-148-bytes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
the results are 216 Bytes in 64 Bit system and 148 Bytes in 32 Bit system
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
The contents of FILE structure are implementation-specific (which means they are different in different platforms).
On a 32-bit system, the size of a pointer is usually 4 bytes and on a 64-bit system the size of a pointer is usually 8 bytes.
So the difference in the size you see (216 - 148 = 68) can be easily accounted for. (From what I remember this structure has about 15 pointers in Ubuntu GCC).
And apart from pointers the sizes of other types like int, long (which can be part of FILE structure) etc can differ from 32 and 64 bits systems.
Including @MatteoItalia comments below:
In particular, using this definition from glibc (and _IO_USE_OLD_IO_FILE undefined) I do get 148 bytes (with 4-byte int, pointers, size_t and __off_t).
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as 15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t) is 40 on 32 bit, but 24 on 64 bit)
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
thank you , I got your point about difference between 32bit and 64 bit system . Now can you please explain why the size is 148 for 32 bit os.
– new_learner
Nov 26 '18 at 7:26
1
@new_learner because there's 148 byte of data in there? It's really implementation-specific, depending from your system headers; dig them up from your compiler includes directory, sum up the fields sizes (taking padding in account) and you'll see that it'll add up to 148.
– Matteo Italia
Nov 26 '18 at 7:28
1
In particular, using this definition from glibc (and_IO_USE_OLD_IO_FILEundefined) I do get 148 bytes (with 4-byteint, pointers,size_tand__off_t).
– Matteo Italia
Nov 26 '18 at 7:35
1
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)is 40 on 32 bit, but 24 on 64 bit).
– Matteo Italia
Nov 26 '18 at 7:40
1
@MatteoItalia: Can I include your comments in the answer?
– P.W
Nov 26 '18 at 7:42
|
show 2 more comments
the results are 216 Bytes in 64 Bit system and 148 Bytes in 32 Bit system
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
The contents of FILE structure are implementation-specific (which means they are different in different platforms).
On a 32-bit system, the size of a pointer is usually 4 bytes and on a 64-bit system the size of a pointer is usually 8 bytes.
So the difference in the size you see (216 - 148 = 68) can be easily accounted for. (From what I remember this structure has about 15 pointers in Ubuntu GCC).
And apart from pointers the sizes of other types like int, long (which can be part of FILE structure) etc can differ from 32 and 64 bits systems.
Including @MatteoItalia comments below:
In particular, using this definition from glibc (and _IO_USE_OLD_IO_FILE undefined) I do get 148 bytes (with 4-byte int, pointers, size_t and __off_t).
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as 15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t) is 40 on 32 bit, but 24 on 64 bit)
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
thank you , I got your point about difference between 32bit and 64 bit system . Now can you please explain why the size is 148 for 32 bit os.
– new_learner
Nov 26 '18 at 7:26
1
@new_learner because there's 148 byte of data in there? It's really implementation-specific, depending from your system headers; dig them up from your compiler includes directory, sum up the fields sizes (taking padding in account) and you'll see that it'll add up to 148.
– Matteo Italia
Nov 26 '18 at 7:28
1
In particular, using this definition from glibc (and_IO_USE_OLD_IO_FILEundefined) I do get 148 bytes (with 4-byteint, pointers,size_tand__off_t).
– Matteo Italia
Nov 26 '18 at 7:35
1
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)is 40 on 32 bit, but 24 on 64 bit).
– Matteo Italia
Nov 26 '18 at 7:40
1
@MatteoItalia: Can I include your comments in the answer?
– P.W
Nov 26 '18 at 7:42
|
show 2 more comments
the results are 216 Bytes in 64 Bit system and 148 Bytes in 32 Bit system
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
The contents of FILE structure are implementation-specific (which means they are different in different platforms).
On a 32-bit system, the size of a pointer is usually 4 bytes and on a 64-bit system the size of a pointer is usually 8 bytes.
So the difference in the size you see (216 - 148 = 68) can be easily accounted for. (From what I remember this structure has about 15 pointers in Ubuntu GCC).
And apart from pointers the sizes of other types like int, long (which can be part of FILE structure) etc can differ from 32 and 64 bits systems.
Including @MatteoItalia comments below:
In particular, using this definition from glibc (and _IO_USE_OLD_IO_FILE undefined) I do get 148 bytes (with 4-byte int, pointers, size_t and __off_t).
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as 15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t) is 40 on 32 bit, but 24 on 64 bit)
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
the results are 216 Bytes in 64 Bit system and 148 Bytes in 32 Bit system
can anyone explain why it is showing this much size , as I checked the structure members are mostly pointers .
The contents of FILE structure are implementation-specific (which means they are different in different platforms).
On a 32-bit system, the size of a pointer is usually 4 bytes and on a 64-bit system the size of a pointer is usually 8 bytes.
So the difference in the size you see (216 - 148 = 68) can be easily accounted for. (From what I remember this structure has about 15 pointers in Ubuntu GCC).
And apart from pointers the sizes of other types like int, long (which can be part of FILE structure) etc can differ from 32 and 64 bits systems.
Including @MatteoItalia comments below:
In particular, using this definition from glibc (and _IO_USE_OLD_IO_FILE undefined) I do get 148 bytes (with 4-byte int, pointers, size_t and __off_t).
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as 15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t) is 40 on 32 bit, but 24 on 64 bit)
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
edited Nov 26 '18 at 11:27
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
answered Nov 26 '18 at 7:23
P.WP.W
14.6k31250
14.6k31250
thank you , I got your point about difference between 32bit and 64 bit system . Now can you please explain why the size is 148 for 32 bit os.
– new_learner
Nov 26 '18 at 7:26
1
@new_learner because there's 148 byte of data in there? It's really implementation-specific, depending from your system headers; dig them up from your compiler includes directory, sum up the fields sizes (taking padding in account) and you'll see that it'll add up to 148.
– Matteo Italia
Nov 26 '18 at 7:28
1
In particular, using this definition from glibc (and_IO_USE_OLD_IO_FILEundefined) I do get 148 bytes (with 4-byteint, pointers,size_tand__off_t).
– Matteo Italia
Nov 26 '18 at 7:35
1
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)is 40 on 32 bit, but 24 on 64 bit).
– Matteo Italia
Nov 26 '18 at 7:40
1
@MatteoItalia: Can I include your comments in the answer?
– P.W
Nov 26 '18 at 7:42
|
show 2 more comments
thank you , I got your point about difference between 32bit and 64 bit system . Now can you please explain why the size is 148 for 32 bit os.
– new_learner
Nov 26 '18 at 7:26
1
@new_learner because there's 148 byte of data in there? It's really implementation-specific, depending from your system headers; dig them up from your compiler includes directory, sum up the fields sizes (taking padding in account) and you'll see that it'll add up to 148.
– Matteo Italia
Nov 26 '18 at 7:28
1
In particular, using this definition from glibc (and_IO_USE_OLD_IO_FILEundefined) I do get 148 bytes (with 4-byteint, pointers,size_tand__off_t).
– Matteo Italia
Nov 26 '18 at 7:35
1
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)is 40 on 32 bit, but 24 on 64 bit).
– Matteo Italia
Nov 26 '18 at 7:40
1
@MatteoItalia: Can I include your comments in the answer?
– P.W
Nov 26 '18 at 7:42
thank you , I got your point about difference between 32bit and 64 bit system . Now can you please explain why the size is 148 for 32 bit os.
– new_learner
Nov 26 '18 at 7:26
thank you , I got your point about difference between 32bit and 64 bit system . Now can you please explain why the size is 148 for 32 bit os.
– new_learner
Nov 26 '18 at 7:26
1
1
@new_learner because there's 148 byte of data in there? It's really implementation-specific, depending from your system headers; dig them up from your compiler includes directory, sum up the fields sizes (taking padding in account) and you'll see that it'll add up to 148.
– Matteo Italia
Nov 26 '18 at 7:28
@new_learner because there's 148 byte of data in there? It's really implementation-specific, depending from your system headers; dig them up from your compiler includes directory, sum up the fields sizes (taking padding in account) and you'll see that it'll add up to 148.
– Matteo Italia
Nov 26 '18 at 7:28
1
1
In particular, using this definition from glibc (and
_IO_USE_OLD_IO_FILE undefined) I do get 148 bytes (with 4-byte int, pointers, size_t and __off_t).– Matteo Italia
Nov 26 '18 at 7:35
In particular, using this definition from glibc (and
_IO_USE_OLD_IO_FILE undefined) I do get 148 bytes (with 4-byte int, pointers, size_t and __off_t).– Matteo Italia
Nov 26 '18 at 7:35
1
1
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as
15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t) is 40 on 32 bit, but 24 on 64 bit).– Matteo Italia
Nov 26 '18 at 7:40
As for the difference, there are more than 17 pointers (plus padding!) which would account for the difference, but there's also some explicit padding at the end that complicates the calculation (it does become smaller on 64 bit, as
15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t) is 40 on 32 bit, but 24 on 64 bit).– Matteo Italia
Nov 26 '18 at 7:40
1
1
@MatteoItalia: Can I include your comments in the answer?
– P.W
Nov 26 '18 at 7:42
@MatteoItalia: Can I include your comments in the answer?
– P.W
Nov 26 '18 at 7:42
|
show 2 more comments
The contents and size of the FILE structure is entirely specific to the implementation. it happens to be 216 bytes on your OS in 64-bit mode and 148 in 32-bit mode. The difference could come from the differing sizes of some of the members of this structure between 32-bit and 64-bit mode: pointers are larger, as well as size_t and file positions, it really depends on how the C library handles the standard streams.
Note that some extra information might be stored outside the structure... in any case you cannot save a FILE to a local variable and restore it safely.
Note that FILE could also be an incomplete type: a typedef for a pointer to a structure whose definition is absent, in which case sizeof(FILE) would cause a compilation error. The main reason to put the definition in the <stdio.h> header is to allow macros to access members directly. Take a look into your <stdio.h> file and look for other implementations in open source, such as the newlib or the glibc.
Furthermore, the C Standard does not mandate that FILE be a typedef for a structure: it might not be a structure, it could be defined as an int.
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
@Note that FILE might not be a structure at all. It could be defined as an int . FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h)
– new_learner
Nov 26 '18 at 9:06
2
@new_learner FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h) That's true only for the one implementation you looked at. There are others - many others.
– Andrew Henle
Nov 26 '18 at 10:12
add a comment |
The contents and size of the FILE structure is entirely specific to the implementation. it happens to be 216 bytes on your OS in 64-bit mode and 148 in 32-bit mode. The difference could come from the differing sizes of some of the members of this structure between 32-bit and 64-bit mode: pointers are larger, as well as size_t and file positions, it really depends on how the C library handles the standard streams.
Note that some extra information might be stored outside the structure... in any case you cannot save a FILE to a local variable and restore it safely.
Note that FILE could also be an incomplete type: a typedef for a pointer to a structure whose definition is absent, in which case sizeof(FILE) would cause a compilation error. The main reason to put the definition in the <stdio.h> header is to allow macros to access members directly. Take a look into your <stdio.h> file and look for other implementations in open source, such as the newlib or the glibc.
Furthermore, the C Standard does not mandate that FILE be a typedef for a structure: it might not be a structure, it could be defined as an int.
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
@Note that FILE might not be a structure at all. It could be defined as an int . FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h)
– new_learner
Nov 26 '18 at 9:06
2
@new_learner FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h) That's true only for the one implementation you looked at. There are others - many others.
– Andrew Henle
Nov 26 '18 at 10:12
add a comment |
The contents and size of the FILE structure is entirely specific to the implementation. it happens to be 216 bytes on your OS in 64-bit mode and 148 in 32-bit mode. The difference could come from the differing sizes of some of the members of this structure between 32-bit and 64-bit mode: pointers are larger, as well as size_t and file positions, it really depends on how the C library handles the standard streams.
Note that some extra information might be stored outside the structure... in any case you cannot save a FILE to a local variable and restore it safely.
Note that FILE could also be an incomplete type: a typedef for a pointer to a structure whose definition is absent, in which case sizeof(FILE) would cause a compilation error. The main reason to put the definition in the <stdio.h> header is to allow macros to access members directly. Take a look into your <stdio.h> file and look for other implementations in open source, such as the newlib or the glibc.
Furthermore, the C Standard does not mandate that FILE be a typedef for a structure: it might not be a structure, it could be defined as an int.
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
The contents and size of the FILE structure is entirely specific to the implementation. it happens to be 216 bytes on your OS in 64-bit mode and 148 in 32-bit mode. The difference could come from the differing sizes of some of the members of this structure between 32-bit and 64-bit mode: pointers are larger, as well as size_t and file positions, it really depends on how the C library handles the standard streams.
Note that some extra information might be stored outside the structure... in any case you cannot save a FILE to a local variable and restore it safely.
Note that FILE could also be an incomplete type: a typedef for a pointer to a structure whose definition is absent, in which case sizeof(FILE) would cause a compilation error. The main reason to put the definition in the <stdio.h> header is to allow macros to access members directly. Take a look into your <stdio.h> file and look for other implementations in open source, such as the newlib or the glibc.
Furthermore, the C Standard does not mandate that FILE be a typedef for a structure: it might not be a structure, it could be defined as an int.
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
edited Nov 26 '18 at 22:12
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
answered Nov 26 '18 at 8:46
chqrliechqrlie
60k746102
60k746102
@Note that FILE might not be a structure at all. It could be defined as an int . FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h)
– new_learner
Nov 26 '18 at 9:06
2
@new_learner FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h) That's true only for the one implementation you looked at. There are others - many others.
– Andrew Henle
Nov 26 '18 at 10:12
add a comment |
@Note that FILE might not be a structure at all. It could be defined as an int . FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h)
– new_learner
Nov 26 '18 at 9:06
2
@new_learner FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h) That's true only for the one implementation you looked at. There are others - many others.
– Andrew Henle
Nov 26 '18 at 10:12
@Note that FILE might not be a structure at all. It could be defined as an int . FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h)
– new_learner
Nov 26 '18 at 9:06
@Note that FILE might not be a structure at all. It could be defined as an int . FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h)
– new_learner
Nov 26 '18 at 9:06
2
2
@new_learner FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h) That's true only for the one implementation you looked at. There are others - many others.
– Andrew Henle
Nov 26 '18 at 10:12
@new_learner FILE is a typedefed structure : typedef struct _IO_FILE FILE ; (typedefed in stdio.h and declared in libio.h) That's true only for the one implementation you looked at. There are others - many others.
– Andrew Henle
Nov 26 '18 at 10:12
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53476148%2fwhy-the-size-of-file-structure-instance-is-216-bytes-in-64-bit-os-and-148-bytes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
7
The implementation's internal format for
FILEnotwithstanding (you shoudn't have to care) why are you using%dfor printing asize_texpression? That should be%zu. And if the members are "mostly pointers" consider that each pointer in a 32bit vs 64bit representation will literally double in size going from the former to the latter.– WhozCraig
Nov 26 '18 at 7:11
7
It most certainly does play an important role. Using the wrong format specifier is basically lying to
printf, and invokes undefined behavior if/when the arguments are not of the precise type expected by the corresponding specifier. There's enough UB in the coding world; no reason to add to it with trivialities, especially when they're simple enough to just do the correct thing in the first place. Ex: ifsize_tandintare 64 and 32 bit respectively on your architecture (most 64bit arches are such), then you'd be shoving a 64bit value to a function expecting a 32bit value.– WhozCraig
Nov 26 '18 at 7:21
1
I checked with %zu and updated the same , thank you .
– new_learner
Nov 26 '18 at 7:24
1
BTW, in practice, a
FILEtakes much more resources: some buffer (kilobytes) and a file descriptor (resource known to the operating system kernel)– Basile Starynkevitch
Nov 26 '18 at 7:53
1
Which values did you expect and why?
– Gerhardh
Nov 26 '18 at 9:04