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

Oh whow, what a discussion. Please note that I won't be able to answer all of
the 50 mails currently in my inbox.

On Fri, Aug 10, 2012 at 01:43:37PM +0200, Oliver Schmidt wrote:
> 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.

I would prefer not to suppport non standard hardware if this comes with a
large overhead for programs that do not care about this hardware. I'm not
against support for non standard hardware when this can be done with no or
only a small overhead. You can even extend this to "rare hardware". The 1581
for example has something like subdirectories, but these aren't supported by
the library.

In the given case the argument was taken from the ongoing discussion.

> >   * Everybody has his pet syntax for this purpose.
>
> A missing standard is from my perspective no excuse to not support it at all.

If you write a program and require the user to enter a file name, you will
need to teach him the required syntax. This is difficult if he is used to
something else.

> 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.

This doesn't allow you to distinguish between unit number and device number.
Any of both may be given alone.

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

opendir does probably need another parser. The existing routine checks for a
'$' (name for directory) and switches into a special parsing mode. Adding a
drive number won't make that better.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.