The sense of the result of FileIsReadOnly seems to be inverted - see attched patch
Colin

you wrote

The sense of the result of FileIsReadOnly seems to be inverted - see attched patch Colin

Thanks, applied

Peter

Hello all,

I have some ideas about the bug #2363 (Unfixed Error export problem). I see two ways to solve this problem but I'm not sure that I'm able to realize them.
First way (may be wrong):
generating edata sections (or their analogs for non-Windows platforms) vor every unit that contains exports clause and making a chain of these sections using the same way as used to multi-units VMT generation.
Second way: storing exported items info in PPU.

Don't know what you mean with multi-units VMT. A Class/Object/VMT is defined only in a single unit.

I don't think that is possible. What to do with the index numbering across units?

Second way: storing exported items info in PPU.

That is possible. It needs a new ppuentry that will contain the following items per export:

- procdef reference
- exported name
- exported index

Hello Peter,

PV> That is possible. It needs a new ppuentry that will contain the following PV> items per export:

PV> - procdef reference
PV> - exported name
PV> - exported index

May be it is possible to avoid adding new entries. I looked a little... Two kinds of statements can be exported: procedures/functions and (on some platforms) variables.

tvarsym contains a field varoptions that is a set of tvaroption. Tvaroption already has vo_is_exported as a possible value.

tprocsym has a field is_global : boolean (unfortunately, only under {$ifdef GDB}). This field could be easily changed to byte with 3 possible values: 0 - local, 1 - global, 2 - global and exported. That could cause no changes in binary PPU structure and no changes in other parts of compiler where this field is already used (only a typecast byte to boolean is needed). Am I right?

That is not possible. Because the exports can be in a different unit. You can't change fields in ppu entries that are in other units.