Re: [cc65] Re: some patches

Hi,

1. From my perspective there are quite some reasons to have a concept
for libraries overriding parts of other libraries:

As far as I understand currently any symbol referenced from a module
in a certain library will always searched first inside that library.
This means in example that it isn't possible to override
open/read/write/close from the C library when they are referenced by
fopen/fread/fwrite/fclose.

Maybe the semantics of --start-group / --end-group could be modified
in a way that a library mentioned inside a group _before_ a second
library is searched _before_ that second library for symbols
referenced in that second library. This would allow to override
symbols from the C library.

2. cc65 features loadable drivers for several hardware/interface
classes. But what is the usecase of loadable drivers (compared to
libraries)? If the program is only intended to run on a single machine
then there's no difference. But if the program is intended to run on
many machines then the loadable drivers can avoid generating several
variants of the program linked with several libraries. Rather the
individual user can select the loadable driver suitable for his
hardware.

I'm no CBM insider but I seem to understand that there are quite some
diverse solutions regarding disk I/O. From that perspective disk I/O
clearly is a usecase for loadable drivers - at least on the CBMs. The
only special thing is that there needs to be a default driver to
actually load the loadable driver. But as far as I understand the
Kernal allows for such a default driver to be very simple and very
small. BTW: Contiki 1.x implemented this way a "fastloader" loadable
driver loaded by the Kernal. And for PCs it's totally normal to use
the INT13 BIOS calls to load disk drivers.

Clearly not every cc65 program doing disk I/O requires addional
capabilities beyond the current implementation. So it's clearly not
desirable to have the module loading code inlcuded into every program
doing disk I/O.

As a result 1.) and 2.) could be combined: A library implementing
open/read/write/close overriding the implementations in the C library.
The implementation in that library loads a disk I/O driver called
'std.dsk' (if found). Users can choose among the exsisting disk I/O
drivers the one matching their needs/their hardware and copy it as
'std.dsk' to the disk/image in question.

Maybe a true case of german over-engineering, but maybe the solution
to the seemingly broad range of disk I/O approaches on the CBMs.

Regards, Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.