David R Tribble <david@tribble.com> writes:

>Steve Clamage wrote:
>>
>> No, by definition, an ABI assures binary compatibility of
>> object code and data. The C ABI must include all of the C
>> standard library interfaces.

>This is surprising, sincs this means that the contents of struct tm,
>FILE, and others can't be improved upon by other compiler/library
>vendors.  But after some thought, I see that makes sense - it
>allows programs compiled by various compilers to all make use of the
>same standard libraries.

But let's keep in mind that an ABI applies to a single platform --
which I'll define as a combination of instruction set
architecture and operating system.

Typically, the OS vendor specifies the ABI for each supported
platform.  Sometimes there is a de facto ABI due to the dominance
of one compiler on a platform.

Any compiler or library implementor can choose to follow the
(formal or informal) ABI or not. Where there is an accepted ABI
it usually makes sense to follow it.

Where chaos reigns, as was the case with MSDOS, different compiler
implementors can provide different and incompatible ABIs.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> David R Tribble <david@tribble.com> writes:
>
> >Steve Clamage wrote:
> >>
> >> If you intend to link code from different compilers, they must
> >> aggree on what is usually called an Application Binary Interface,
> >> which specifies all of those details.
> >>
> >> The C standard library would be part of the ABI, and compilers
> >> that conform to the ABI would use all the same interfaces --
> >> including the layout of struct tm.
>
> >Assuming that the code produced by all of those vendors calls
> >the same (system-supplied) library, which is not typically the
> >case.
>
> No, by definition, an ABI assures binary compatibility of
> object code and data. The C ABI must include all of the C
> standard library interfaces.

This is surprising, sincs this means that the contents of struct tm,
FILE, and others can't be improved upon by other compiler/library
vendors.  But after some thought, I see that makes sense - it
allows programs compiled by various compilers to all make use of the
same standard libraries.

(And yes, I was confusing "ABI" with "API".)

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Waranun Bunjongsat <bunjonwa@trek.CS.ORST.EDU> writes:
> However, if I can expect the order of the data in struct tm, I would
> just be able to use the offset of my data related with the head of
> struct tm to store and retrieve data directly into struct tm.

You can do that with `offsetof(struct tm, tm_year)', etc.  But the
value of this offset may be different from one platform to another.


paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc <prj@po.cwru.edu> wrote in message
news:m3emh04zh9.fsf@multivac.student.cwru.edu...
> You can do that with `offsetof(struct tm, tm_year)', etc.  But the
> value of this offset may be different from one platform to another.

That's an interesting one that I never heard of before.  I'll file it away
for furture use.

Greg Brewer





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Waranun Bunjongsat <bunjonwa@trek.CS.ORST.EDU> writes:

>On 17 Aug 1999, Steve Clamage wrote:

>> "Waranun Bunjongsat" <bunjonwa@earthlink.net> writes:
>>
>> >I have read in gnu standard C that the data in "struct tm" can be in any
>> >order as long as it covers all of the data in the specification.
>>
>> Right.
>> ...
>>
>> If you intend to link code from different compilers, they must
>> aggree on what is usually called an Application Binary Interface,
>> which specifies all of those details.
>>
>> The C standard library would be part of the ABI, and compilers
>> that conform to the ABI would use all the same interfaces --
>> including the layout of struct tm.

> Hmmm, it is interesting about ABI. However, I'm looking so far
>until the binary interface. Simply, at the programming level, I can't
>touch struct tm at all. This is because I do not know the specific order
>of its data.

You don't need to know the order. On all implementations that
conform to the same ABI the order is the same. You can dump the
binary contents of a tm object to a file, and read it back in.
As long as the reading program conforms to the same ABI as the
writing program, everything is fine.

By definition, an ABI assures binary compatibility of object code
and data.

If you need to read the data using something else, you have more
than differing struct offsets to worry about. You also need to
worry about the sizes, alignment, representation, and byte order
of values stored in each field of the tm object.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:

>Steve Clamage wrote:
>>
>> If you intend to link code from different compilers, they must
>> aggree on what is usually called an Application Binary Interface,
>> which specifies all of those details.
>>
>> The C standard library would be part of the ABI, and compilers
>> that conform to the ABI would use all the same interfaces --
>> including the layout of struct tm.

>Assuming that the code produced by all of those vendors calls
>the same (system-supplied) library, which is not typically the
>case.

No, by definition, an ABI assures binary compatibility of
object code and data. The C ABI must include all of the C
standard library interfaces.

>This is especially true for things like struct tm, which are
>implemented by each vendor as a library shipped with its compiler;
>it is entirely plausible that every vendor implements struct tm
>differently, just as they are free to implement the FILE and time_t
>types as they see fit.

If they conform to the same ABI, they must be identical at the
binary level -- by definition of ABI.

For example, there is a published ABI for Solaris on each supported
platform. Sun provides ABI-conforming C implementations, and so do
various third-party vendors. You can take object code modules
compiled by any combination of these compilers and link them
together without difficulty.

> Only system interface types (such as the
>arguments to a system-specific open() function, for example) need to
>adhere to any kind of ABI.

You are thinking of an API, an Application Programming Interface.

>(This assumes that you're not attempting to run a program compiled
>by vendor A with vendor B's interface libraries.  Most C++ compilers,
>in fact, will not let you do this.)

That is because there aren't any ABIs for C++ implementations yet.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> "Waranun Bunjongsat" <bunjonwa@earthlink.net> writes:
>
> >I have read in gnu standard C that the data in "struct tm" can be in any
> >order as long as it covers all of the data in the specification.
>
> Right.
>
> >In my understanding, this will be depended on each implementation, e.g. gnu
> >C and turbo C may implement struct tm differently, as above example.
>
> Right.
>
> >... if user defines a data structure or a data manipulator
> >which will interact with "struct tm" in a binary level, the data structure
> >will not work the same across the compiler. Or the simplest case is when
> >user want to use the data that was processed and stored by program compiled
> >on one compiler, with another version of the same program compiled on
> >another compiler. The two same programs compiled on different compilers may
> >not work the same on the same data.
>
> Right.
>
> But the format of the tm struct is only one of the problems
> in linking code from different compilers.
>
> Here is a small sample of the things than can differ among C
> compilers regarding generated code:
>
> The sizes of the basic types
> The representation of the basic types, especially floating point
> Alignment of the basic types
> Alignment of struct types (sometimes structs have special alignment)
> Calling sequence for functions, especially how parameters are
>     passed and values returned
> Conventions for external names (e.g., added leading underscore)
>
> For C++ (you cross-posted to a C++ newsgroup) the list is much,
> much, much longer.
>
> If you intend to link code from different compilers, they must
> aggree on what is usually called an Application Binary Interface,
> which specifies all of those details.
>
> The C standard library would be part of the ABI, and compilers
> that conform to the ABI would use all the same interfaces --
> including the layout of struct tm.

Assuming that the code produced by all of those vendors calls
the same (system-supplied) library, which is not typically the
case.  This is especially true for things like struct tm, which are
implemented by each vendor as a library shipped with its compiler;
it is entirely plausible that every vendor implements struct tm
differently, just as they are free to implement the FILE and time_t
types as they see fit.  Only system interface types (such as the
arguments to a system-specific open() function, for example) need to
adhere to any kind of ABI.

(This assumes that you're not attempting to run a program compiled
by vendor A with vendor B's interface libraries.  Most C++ compilers,
in fact, will not let you do this.)

-- David R. Tribble, david@tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 17 Aug 1999, Steve Clamage wrote:

> "Waranun Bunjongsat" <bunjonwa@earthlink.net> writes:
>
> >I have read in gnu standard C that the data in "struct tm" can be in any
> >order as long as it covers all of the data in the specification.
>
> Right.
>
> >In my understanding, this will be depended on each implementation, e.g. gnu
> >C and turbo C may implement struct tm differently, as above example.
>
> Right.
>
> >... if user defines a data structure or a data manipulator
> >which will interact with "struct tm" in a binary level, the data structure
> >will not work the same across the compiler. Or the simplest case is when
> >user want to use the data that was processed and stored by program compiled
> >on one compiler, with another version of the same program compiled on
> >another compiler. The two same programs compiled on different compilers may
> >not work the same on the same data.
>
> Right.
>
> But the format of the tm struct is only one of the problems
> in linking code from different compilers.
>
> Here is a small sample of the things than can differ among C
> compilers regarding generated code:
>
> The sizes of the basic types
> The representation of the basic types, especially floating point
> Alignment of the basic types
> Alignment of struct types (sometimes structs have special alignment)
> Calling sequence for functions, especially how parameters are
>     passed and values returned
> Conventions for external names (e.g., added leading underscore)
>
> For C++ (you cross-posted to a C++ newsgroup) the list is much,
> much, much longer.
>
> If you intend to link code from different compilers, they must
> aggree on what is usually called an Application Binary Interface,
> which specifies all of those details.
>
> The C standard library would be part of the ABI, and compilers
> that conform to the ABI would use all the same interfaces --
> including the layout of struct tm.

 Hmmm, it is interesting about ABI. However, I'm looking so far
until the binary interface. Simply, at the programming level, I can't
touch struct tm at all. This is because I do not know the specific order
of its data.

 For example, if I want to operate on the data only year, month and
date, to save the space, I would not want to store all the struct tm into
the memory and storage. In this case, if I know the order of the struct
tm's data element. I can just store and retrieve the year, month, date
data directly into my dummy struct tm and send it to the standard stream
or locale to manipulate it, as normal. However, since I don't know even
how struct tm would be written in the C struct syntax, because I do not
know the order of its data. I would have to copy my data to my dummy
struct tm one by one, for example tm.year=mystruct.year and etc ....

        However, if I have more combinations of year, month, date, hour,
min, sec, weekday, yearday, .... etc., I would have to do the same for all
of them. I would have to create the program (classes/objects) differently
for all of them. However, if I can expect the order of the data in struct
tm, I would just be able to use the offset of my data related with the
head of struct tm to store and retrieve data directly into struct tm.
Therefore, I can only have one program for, say, 20 combinations of my
date/time data. Or else, I would have to do a more inefficient conversion
in order to be able to use one class for all the data, instead of having
to create 20 classes for all of them. I was just surprised that I can't
even write struct tm which is the standard C data into the C struct
format.

Regards,

Waranun,



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

I have read in gnu standard C that the data in "struct tm" can be in any
order as long as it covers all of the data in the specification. That is it
can be

struct tm {
    int sec;
    int min;
    ...
    int mon;
    int year;
};

or it can be

struct tm {
    int year;
    int mon;
    ....
    int min;
    int sec;
};

In my understanding, this will be depended on each implementation, e.g. gnu
C and turbo C may implement struct tm differently, as above example. (ANSI
allowed it so.) However, I would doubt that there could be compatibility
problems. Such as, if user defines a data structure or a data manipulator
which will interact with "struct tm" in a binary level, the data structure
will not work the same across the compiler. Or the simplest case is when
user want to use the data that was processed and stored by program compiled
on one compiler, with another version of the same program compiled on
another compiler. The two same programs compiled on different compilers may
not work the same on the same data.

I do not know whether I misunderstood the ANSI C in this topic.

Any insight and comment would be very appreciated,

Regards,
--
Waranun,




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Waranun Bunjongsat" <bunjonwa@earthlink.net> writes:

>I have read in gnu standard C that the data in "struct tm" can be in any
>order as long as it covers all of the data in the specification.

Right.

>In my understanding, this will be depended on each implementation, e.g. gnu
>C and turbo C may implement struct tm differently, as above example.

Right.

>... if user defines a data structure or a data manipulator
>which will interact with "struct tm" in a binary level, the data structure
>will not work the same across the compiler. Or the simplest case is when
>user want to use the data that was processed and stored by program compiled
>on one compiler, with another version of the same program compiled on
>another compiler. The two same programs compiled on different compilers may
>not work the same on the same data.

Right.

But the format of the tm struct is only one of the problems
in linking code from different compilers.

Here is a small sample of the things than can differ among C
compilers regarding generated code:

The sizes of the basic types
The representation of the basic types, especially floating point
Alignment of the basic types
Alignment of struct types (sometimes structs have special alignment)
Calling sequence for functions, especially how parameters are
    passed and values returned
Conventions for external names (e.g., added leading underscore)

For C++ (you cross-posted to a C++ newsgroup) the list is much,
much, much longer.

If you intend to link code from different compilers, they must
aggree on what is usually called an Application Binary Interface,
which specifies all of those details.

The C standard library would be part of the ABI, and compilers
that conform to the ABI would use all the same interfaces --
including the layout of struct tm.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]