Add unlink(2) implementation for CP/M.

[ibara]

Hello --

When compiling C code for CP/M, unlink is accepted by the compiler via the unistd.h header but then fails when linking due to an undefined reference for _unlink.

This PR adds an unlink implementation for CP/M.

I am not 100% sure the errno = EIO is the correct errno for when cpm_delete_file returns 0xff, but this is good enough for my needs.

Thanks!

[davidgiven]

Thanks very much! I've left a couple of comments.

[ibara]

Hello --

Thanks.
(However, I don't see any comments anywhere...)

[davidgiven]

That is, github review comments, not code comments! They should show up in the github UI here, above this message: #235

[ibara]

Embarrassingly, my GitHub UI appears to be broken (though I am using Chrome on Windows atm): there is no github review anywhere for me...

[tkchia]

Hello @ibara, hello @davidgiven,

I do not see any GitHub review comments either (?). Meanwhile I have a few queries of my own on this PR:

• Is it really necessary to find an empty slot in the __fd[] array? I would think that the FCB could simply be created on the stack, and unlink can do the file deletion from there.
• If the code is going to touch the __fd[] array, then should it use __fd[] to check that the file to be unlink-ed is not currently open? Is it OK under CP/M to remove a file that is still open?

(My knowledge of the CP/M interface is admittedly quite limited — but I had been looking at Microsoft's GW-BASIC implementation of the KILL command for deleting files, which uses CP/M-like FCBs under MS-DOS 1.x.)

Thank you!

[ibara]

My knowledge of the CP/M interface is also limited. I freely and fully admit to stealing this code from another library file (maybe open?) and modifying it until it did the right thing for my use case. I am sure it needs lots of improvement!

[davidgiven]

It's been a while since I looked at this code, but I believe that this chunk is trying to find a free FCBE structure for use when parsing the filename, right? I think it would actually be more efficient to have a static structure used by unlink() instead --- the size of the structure is probably smaller than the size of the code needed to manage allocating one.

[davidgiven]

IIUIC, this will leak the FCBE if the call succeeds. (I assume you don't want to allocate one permanently, right?)

[davidgiven]

Very very belatedly someone told me that github doesn't actually send reviews until you do something unobvious. Hopefully I've done that now. Sorry for the delay.