Home > Archive > Fortran > December 2006 > F2K C Interoperability - SIZEOF
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
F2K C Interoperability - SIZEOF
|
|
| gary.l.scott@lmco.com 2006-12-14, 7:06 pm |
| Was searching the F2k document and did not locate a "sizeof" intrinsic.
Thought it might be called "c_sizeof" or something else?? A large
percentage of c structures in the Windows API have the first element
set to the size of the structure in bytes. Example:
structure%comp1 = sizeof(structure)
I hope we're not supposed to use IOLENGTH for that, makes for a messy
solution, or need to create your own substitute sizeof function (CVF
has one already, was thinking about portability since that one is
almost ubiquitous in c code).
| |
| Richard E Maine 2006-12-14, 7:06 pm |
| <gary.l.scott@lmco.com> wrote:
> Was searching the F2k document and did not locate a "sizeof" intrinsic.
> Thought it might be called "c_sizeof" or something else??
I pushed for a storage_size intrinsic in f2003, but didn't make it. I
think such a thing is belatedly in the f2008 draft, but it isn't in
f2003.
> I hope we're not supposed to use IOLENGTH for that, makes for a messy
> solution,
Not only is it messy, it isn't necessarily the right answer. Look at
what the definition of iolength actually says in the standard. Read it
carefully and literally. It says nothing about the amount of memory that
something takes up - only about what kind of record length you need for
unformatted I/O of it. While those are likely to be highly related,
there are many ways for them not to be the same thing.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2006-12-14, 7:06 pm |
| Richard E Maine <nospam@see.signature> wrote:
[color=darkred]
[color=darkred]
> Not only is it messy, it isn't necessarily the right answer. Look at
> what the definition of iolength actually says in the standard. Read it
> carefully and literally. It says nothing about the amount of memory that
> something takes up - only about what kind of record length you need for
> unformatted I/O of it. While those are likely to be highly related,
> there are many ways for them not to be the same thing.
C's sizeof() gives the length including any padding at the end.
It is the spacing between elements of an array of such items,
especially if one is a struct or union.
IOLENGTH of one and two units of the specified type should
differ by the appropriate amount, assuming that all padding except at
the end is written out. I suppose that isn't required, though.
(It might remove internal padding before writing.)
-- glen
| |
| gary.l.scott@lmco.com 2006-12-14, 7:06 pm |
|
glen herrmannsfeldt wrote:
> Richard E Maine <nospam@see.signature> wrote:
>
>
>
>
> C's sizeof() gives the length including any padding at the end.
> It is the spacing between elements of an array of such items,
> especially if one is a struct or union.
>
> IOLENGTH of one and two units of the specified type should
> differ by the appropriate amount, assuming that all padding except at
> the end is written out. I suppose that isn't required, though.
> (It might remove internal padding before writing.)
>
I prefer in most cases that it be removed when written to disk, so I
think we need an option to specify this behavior for stream read/writes
so that I can optionally process the binary information without needing
to know internal padding mechanisms.
> -- glen
| |
| Dan Nagle 2006-12-14, 7:06 pm |
| Hello,
Richard E Maine wrote:
> <gary.l.scott@lmco.com> wrote:
>
>
> I pushed for a storage_size intrinsic in f2003, but didn't make it. I
> think such a thing is belatedly in the f2008 draft, but it isn't in
> f2003.
It's in the f08 draft. It's a little harder to do, or perhaps
Alek wanted a more general version, but it's there. IIRC, there's
also a separate c_sizeof(), in the iso_c_binding module.
>
> Not only is it messy, it isn't necessarily the right answer. Look at
> what the definition of iolength actually says in the standard. Read it
> carefully and literally. It says nothing about the amount of memory that
> something takes up - only about what kind of record length you need for
> unformatted I/O of it. While those are likely to be highly related,
> there are many ways for them not to be the same thing.
The storage_size() intrinsic is defined to be the size
of an array element of its argument. That way, it includes
any padding needed. The c_sizeof() is defined in terms
of the companion processor, so it's highly variable.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Dick Hendrickson 2006-12-14, 7:06 pm |
| gary.l.scott@lmco.com wrote:
> glen herrmannsfeldt wrote:
>
> I prefer in most cases that it be removed when written to disk, so I
> think we need an option to specify this behavior for stream read/writes
> so that I can optionally process the binary information without needing
> to know internal padding mechanisms.
F2008 pretty much disallows padding for stream files. Data is
transferred in "File Storage Units" and the processor can't impose
alignment restrictions on unformatted transfers that prevent values
from being written at any FSU. If you have access to the F2008 drafts,
look at section 9.2.4 and then 9.2.2.3 for the details. That's easier
than me trying to reformat and quote them ;(.
The standard pretty much can't prohibit some forms of padding. Suppose
a processor supports a 1 bit logical type. hard to imagine that
working well for stream I/O without some padding.
Dick Hendrickson
>
>
| |
| gary.l.scott@lmco.com 2006-12-14, 7:06 pm |
|
Dick Hendrickson wrote:
> gary.l.scott@lmco.com wrote:
>
> F2008 pretty much disallows padding for stream files. Data is
> transferred in "File Storage Units" and the processor can't impose
> alignment restrictions on unformatted transfers that prevent values
> from being written at any FSU. If you have access to the F2008 drafts,
> look at section 9.2.4 and then 9.2.2.3 for the details. That's easier
> than me trying to reformat and quote them ;(.
>
> The standard pretty much can't prohibit some forms of padding. Suppose
> a processor supports a 1 bit logical type. hard to imagine that
> working well for stream I/O without some padding.
>
Yes, that one is less surprising usually, although would need to know
whether the said padding is prefixed or suffixed (hopefully one of
those two).
[color=darkred]
> Dick Hendrickson
| |
| Dick Hendrickson 2006-12-14, 7:06 pm |
| Richard E Maine wrote:
> <gary.l.scott@lmco.com> wrote:
>
>
> I pushed for a storage_size intrinsic in f2003, but didn't make it. I
> think such a thing is belatedly in the f2008 draft, but it isn't in
> f2003.
>
There's a c_sizeof(x) function in the c interoperability section of
F2008. The description pretty much says "returns what the c c_sizeof
function would return. It's not an intrinsic function. None of the
functions in the intrinsic modules are intrinsic. I don't remember why
that is, but there is a good reason.
There's also a storage_size intrinsic function which returns the storage
size in bits of an array element of the same kind as its argument.
There was a lot of hassle getting the words right for this one (or maybe
I should have left out the "right" :( ). If you have access to the
draft, this would be a good time to look at both functions and see if
they do the right thing. If not, I could try to cut and paste, but it's
a bugger because there is so much formatting in the function
descriptions.
Dick Hendrickson
>
> Not only is it messy, it isn't necessarily the right answer. Look at
> what the definition of iolength actually says in the standard. Read it
> carefully and literally. It says nothing about the amount of memory that
> something takes up - only about what kind of record length you need for
> unformatted I/O of it. While those are likely to be highly related,
> there are many ways for them not to be the same thing.
>
| |
| Brooks Moses 2006-12-14, 7:06 pm |
| Dick Hendrickson wrote:
> F2008 pretty much disallows padding for stream files. Data is
> transferred in "File Storage Units" and the processor can't impose
> alignment restrictions on unformatted transfers that prevent values
> from being written at any FSU. If you have access to the F2008 drafts,
> look at section 9.2.4 and then 9.2.2.3 for the details. That's easier
> than me trying to reformat and quote them ;(.
>
> The standard pretty much can't prohibit some forms of padding. Suppose
> a processor supports a 1 bit logical type. hard to imagine that
> working well for stream I/O without some padding.
That doesn't sound like disallowing padding to me. It sounds like
restricting the padding in such a way that only one form of alignment is
permitted (as opposed to allowing different alignments for
differently-sized objects), which is a considerably weaker restriction.
Obviously, if you choose your file storage unit to be a byte, the only
object that gets padded is a 1-bit logical. But a processor could
certainly pad things to (multiples of) four bytes per object if it
declared the file storage unit to be four bytes in size, for example.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Richard E Maine 2006-12-14, 10:05 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> IOLENGTH of one and two units of the specified type should
> differ by the appropriate amount, assuming that all padding except at
> the end is written out.
It assumes many, many more things than that. Again, actually read the
IOLENGTH description. It says nothing at all about size in memory. It is
about unformatted record lengths.
For a start, note that a system is not required to support records of
arbitrary size. It could well be that a system only supported, for
example, unformaatted records that were a multiple of 4 bytes in size.
In that case, ask about a 1-byte entity and the answer is likely to be
4. In theory, things could be worse than that. For example, records
might be multiples of 256 bytes.
What you will see in current common practice is one thing. But it is
*NOT* guaranteed by the standard.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Jugoslav Dujic 2006-12-15, 8:07 am |
| gary.l.scott@lmco.com wrote:
| Was searching the F2k document and did not locate a "sizeof" intrinsic.
| Thought it might be called "c_sizeof" or something else?? A large
| percentage of c structures in the Windows API have the first element
| set to the size of the structure in bytes. Example:
|
| structure%comp1 = sizeof(structure)
|
| I hope we're not supposed to use IOLENGTH for that, makes for a messy
| solution, or need to create your own substitute sizeof function (CVF
| has one already, was thinking about portability since that one is
| almost ubiquitous in c code).
SIZE(TRANSFER(structure, chararray)) also suffers from problems IIRC,
but I find it a bit nicer and perhaps a bit more portable than IOLENGTH.
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
| |
| Dick Hendrickson 2006-12-15, 7:06 pm |
| Brooks Moses wrote:
> Dick Hendrickson wrote:
>
> That doesn't sound like disallowing padding to me. It sounds like
> restricting the padding in such a way that only one form of alignment is
> permitted (as opposed to allowing different alignments for
> differently-sized objects), which is a considerably weaker restriction.
>
> Obviously, if you choose your file storage unit to be a byte, the only
> object that gets padded is a 1-bit logical. But a processor could
> certainly pad things to (multiples of) four bytes per object if it
> declared the file storage unit to be four bytes in size, for example.
Yes. That's pretty much what the standard says. In a non-normative
note it strongly recommends using 8 bits as the File Storage Unit. That
matches common practice, and is likely to match all future file
systems (at least for a while). A processor is free to use 1 bit
for a FSU.
Technically, anything smaller than a FSU needs to be padded. Not only
1 bit logicals, but also 6 bit characters, 5 bit reals, etc. There just
aren't a lot of those around nowadays.
Dick Hendrickson
>
> - Brooks
>
>
|
|
|
|
|