z80 Development Kit
You are not logged in.
Here is a tricky one..
the way freopen_z88 passes its parameters to open_z88 was historically wrong:
Which makes me suppose that the right declaration should have been:
extern int __LIB__ open_z88(far char *name, mode_t mode, int flags, char *explicit, size_t len);
*now* like this in fcntl.h, but historically set with the mode and flags parameters inverted.
It has the effect of making "fopen" on some platform work as if all the files were open "for read" instead of WRITE or APPEND or whatever.
So the final behaviour depends on if the libraries were built basing on the specifications or by 'tuning'and testing them.
Further side effect we have a mixture of funny situations in the sources, some open routine swithes its condition on a 'flags' named variable compared to the "mode" options, the CP/M code declares mode_t for flags and int for mode.
Also it seems the dependency chain between the several open functions varies on the target flavour, some sources are written in assembler and testing this stuff in not always easy.. so the solution seems needing an unexpected effort.
First thing to do.. a couple of common test programs for both open() and fopen(), I'll dig i nthe SDCC regression test suite
After further investigations it seems the bug is only 'cosmetics stuff'.
It seems to work quite well indeed, there is just a readability limit due to the different ways to classify the file status in the different source layers(ie file flags, file open mode, cpm style flags).