What's the problem with just adding a new 'extended private
stuff' field to
the very end of the struct and allocating one of the remaining flag
bits to
say if it's present or not?
That requires to have a version of the library that can work without
it, and it's one more requirement on th
On 08 November 2006 08:13, FX Coudert wrote:
>> Suggestion: We should make sure we can accommodate F2003 with
>> 4.2 and 4.3 by increasing the possible number of flags as needed.
>
> I'm in favour of that, and I already started writing the necessary
> patch. But it looks like we'll have to bump
Suggestion: We should make sure we can accommodate F2003 with
4.2 and 4.3 by increasing the possible number of flags as needed.
I'm in favour of that, and I already started writing the necessary
patch. But it looks like we'll have to bump the so number a last
time, for 4.3, and then make th
On Tue, Nov 07, 2006 at 06:16:50AM -0500, Jakub Jelinek wrote:
> If you want to add over time new fields, if there is space in
> common.flags, you just define a new bit there and add the new field
> to the end of u.p structure if there is space for it. That's the
> easy part.
We're having a flag
On Tue, Nov 07, 2006 at 02:38:39AM -0800, Mike Stump wrote:
> >Now, we also sometimes want to increase the size of the private
> >stuff, and I don't see how we can do that in a way that keeps ABI
> >compatibility, because the bits in the private stuff are always
> >used by the library. So, I
On Tue, Nov 07, 2006 at 10:59:05AM +0100, FX Coudert wrote:
> {
> st_parameter_common common;
> GFC_IO_INT rec;
> [...lots of other struct members...]
> /* Private part of the structure. The compiler just needs
> to reserve enough space. */
> union
> {
> struct
>
On Nov 7, 2006, at 1:59 AM, FX Coudert wrote:
The idea is that common.flags has a bit for every possible member
such as rec, to indicated whether it's present or not. The question
is that we sometimes need to add another struct member (like rec)
in this structure, to implement new features.
