Re: [Tack-devel] Update on porting effort

[<u-...@ae...>]

On Sat, Feb 16, 2019 at 11:54:31AM +0100, David Given wrote:
> Being able to build the ACK on small systems is definitely valuable, and we
> should keep it.

Appreciated.

> That said, I'm not sure that using a custom system library's the right way
> to do this. These days C is much more standard than it was back then and
> the need for custom wrappers to make sure that, e.g., realloc with NULL
> works properly isn't necessary. A lot of the stuff in system is equivalent
> to the standard Posix calls, or is unused completely (sys_lock --- in fact,
> I see that function's not even built!).
> 
> What I'd propose as a compromise is:
> 
> - if a system function is a trivial reimplementation of Posix, replace it
> with the Posix version.
> - *do* replace File* with FILE*. If it turns out to be too expensive later,
> we can replace the buffered stdio with an unbuffered implementation
> equivalent to the one in system, but using the standard interfaces.

I am not sure I am fully following you (any code accidentally
dereferencing *File would break with *FILE because FILE is opaque,
but this might be a non-issue here), assume that you intend to replace
references to the "system" library entries everywhere with corresponding
Posix and stdio equivalents, dropping the library out of existence,
or possibly keeping some entry points not falling under the cases above (?)

If this is a correct interpretation, I do not like to sound negative,
but unfortunately I anticipate some drawbacks.

One is to have to make changes in many files, this implies some
additional work and a risk for subtle breakage.

The other is a loss of the presently sufficient constrained interface.

When someone would have to adapt Ack to a new constrained environment,
one would have a challenge to find out which Posix/libc subset needs
to be ported there.

At that time the necessary set of operation will probably become larger
that today, if more Posix/libc calls will be introduced in different
parts of the code.

It is hard to expect that an Ack developer would always have in mind to
double check whether a certain Posix / C library call is already being
used or not.

> This way we should end up with standard interfaces, which makes things
> easier to work on and maintain, but still allow the small systems.

This particular interface is small (17 entry points?) and the implementation
takes 449 lines in *.[hc] and 324 lines of nroff in the man page.
An implementation of a minimal standard-compatible unbuffered
stdio would probably take at least about the same amount of LOC even if
the man page would become redundant (?).

To get some idea, I checked with avr-libc:
(buffered stdio, so take it with a large grain of salt, but anyway)
The docs say: "only a limited subset of standard IO is implemented"

The non-formatted i/o stdio code:
avr-libc-2.0.0/libc/stdio$ ls *.c | grep -v printf | grep -v scanf | xargs wc | tail -1
 1067  5812 39654 total

Everything in stdio:
avr-libc-2.0.0/libc/stdio$ wc * | tail -1
 4998  23588 160132 total

Rune