Re: [cc65] Apple2 Libraries - Current status of file io ?

Hi!

On Tue, Jul 27, 2004 at 09:37:01AM -0400, jim wrote:
>  int fstat(int fd, struct stat *buf);  /* standard POSIX call */
>  int dio_get_file_info(int fd, struct a2_stat *buf);  /* apple namespace */

I haven't looked further into the issue, but it's probably not a good idea to
add the latter to the dio api. dio was made to allow low level (not file
oriented) disk i/o. The function could be made apple2 specific, however.

> I am looking for a status of what's been done and if we're even
> compatible.  Oliver might be working on ProDOS 16 implementation where
> I'm working in ProDOS 8.

Does this mean there are several different file I/O libraries needed for the
Apple? If so, would it be possible to find a common denominator for all of
them?

> I'm not too sure what you mean by this.  Functionally ? Internal
> structure ? Syntax ?

I'm trying to keep the overall design consistent. This extends into several
areas, internal structure is one of them. Portability is another: Anything
that could be done in a portable way, shouldn't have a platform specific
solution. If it is not possible to make something completely portable, it is
often possible to split it into a platform independent part and a platform
dependent one. I'm trying to make the platform independent part as large as
possible (share as much code among the platforms as possible), because this is
easier to test and to maintain.

> For example: I've coded the Apple libraries to correspond with the POSIX
> calls
> int chdir(const char* path);
> int __fastcall__ close(int fd);
> int creat(const char *name, mode_t mode);
> int flush (int fd);
>  ... and so on ...

Good approach, this is how it should be! However, there's at least one
problem: The library does already have a chdir function in the common
(platform independent) part. It calls a platform specific function named
__syschdir which must return a platform specific error code in A (similar to
remove(), which calls __sysremove).

As you can see from the above, I'm trying to get overall structure right, so
the parts and platform code fit together nicely.

> The hacks in the write and read functions have been worked with so that
> using the STDIO consts work.

Great! This is how it should work. Does reopening these streams also work?

        freopen (stdout, "w", "output.txt");

A perfect solution would even allow to close and reopen the low level file
descriptors (STDIN_FILENO, STDOUT_FILENO and STDERR_FILENO), and reopen them
pointing to a file. This is difficult on some platforms, and not implemented
everywhere, so don't bother if you have hardcoded checks for the standard file
descriptors (which means that reassigning them will not work).

If you're doing larger changes/additions, I would suggest to check back with
me early. It is frustrating if you have spent several weekends to code the
ultimate cc65 addition, just to have me reject it for some reasons you didn't
know when you started. Or, request large changes. And, believe me, having to
do this is also very frustrating for me!

I'm glad about every cc65 contribution. But I do also want to keep cc65 clean
and consistent. It wouldn't be helpful to accept contributions just to be
polite, even if they do not fit into the overall concept or if there are some
other reasons, they shouldn't go into the main distribution. This would
ultimately make cc65 a mess. Checking back with me early helps to resolve any
problems that might arise with a contribution and therefore reduce the
frustration for both of us.

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.