Re: [cc65] Filenames for POSIX functins on CBM targets

Hi,

> We had this discussion several times.

I know.

> As you can see from the discussion that
> comes up (again), the issue is unsatisfactory but a proper solution is
> complex.

Maybe there's a sweet spot between "all" and "nothing"

>   * We want to be able to specify subdirectories.

That sort of surprises me. I seem to remember that your position
usually was (is ?) that optional add-ons to a target (be it software
or hardware) are not entitled to be supported by the C library. So if
they don't fall into a category supported by loadable drivers they're
out of luck.

>   * There are already kernal replacements that use a special syntax for both.
>
>   * Everybody has his pet syntax for this purpose.

A missing standard is from my perspective no excuse to not support it at all.

>   * Most people have just one floppy (#8) and won't really benefit, but will
>     have to pay the price (= memory) for a complex file name parser.

Hm, I personally can't judge on that. But I remember well that I got
quite a lot negative feedback on Contiki in several forums for not
supporting other unit numbers than #8. That negative feedback was the
reason why we changed _curunit from being initialized to #8 to being
initialized from ZP location $BA (?). So I have at least an indication
that there's a real world need for other unit numbers. And I don't
think that people asking for something different than #8 don't have
something connected to #8. From that presumption I deduct that unit
selection is useful.

>   * CBM people are used to specify the device number separately.

Surely. But they are as well used to C64 specific programs written in
asm. Here we're about C programs - that at least I like to be
cross-target. And from that cross-target perspective it is obligatory
that a single string can represent all potential file locations.

If we want to go cross-target we sometimes need to move away from what
people are used to. An example: On the Apple II drives are specified
by a slot (1-7) and a drive (0-1). But the cc65 dio API identifies a
drive by a single number. So I "invented" a mapping and documented it:
http://www.cc65.org/snapshot-doc/apple2-9.html#ss9.3

> A special,
>     cc65 only syntax will confuse most users more than it helps.

Es long as a simple filename without unit and/or drive specification
still works as before a can't see any harm done - beside C libary code
increase. But that increase might be smaller than i.e. the special
handling for opendir() inserted in open() - and opendir() isn't much
used either...

Okay, now for some - maybe naive - thoughts:

Currently we have something like "1#abc.txt". So if that is clearly
understood to mean file "abc.txt" on drive 0 then I have a hard time
to see why "8#1#abc.txt" couldn't be as well understood as file
"abc.txt" on unit 8 on drive 0. The (maybe a little hacky idea) would
be to allow only units 2-15(?) to be selceted this way.

Examples:

filename = "9#abc.txt"
- Unit 9
- *filename+3 processed as today

filename = "8#1#abc.txt"
- Unit 8
- *filename+3 processed as today

filename = "0#abc.txt"
- Default Unit
- *filename+0 processed as today

filename = "1#9#abc.txt"
- Invalid filename

I imagine parsing this could be quite compact and having only an
additional optional prefix allows copy-free processing of the
remainder.

opendir()/chdir() would work with "8#", "1#" or "8#1#" and curdir()
would usually return "8#0#".

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