> Still, I don't understand the reason why strfile does htonl > (strfile.c at line 220 onwards) for all the header fields in the first place, > only for fortune then to undo it (and for unstr to forget doing it, > therefore not working).
The idea is that, as much as possible, we would like files in the system to be portable (if copied) to other systems. > Also, fortune.c at line 1107 does ntohl to undo the htonl of strfile.c > for every header field but for tbl.str_version, which is explicitely > commented out. This seems rather odd -- looking at fortune's behaviour > in the debugger shows that without ntohl the str_version comes in in > reverse byte order, as expected. > > According to CVS, this oddity comes all the way from the > initial import. The second diff fixes that. > > Last, I'd like to suggest that strfile and unstr be included in the base > distribution. It seems strange that their source is there and the > fortune(6) manpage loops through hoops to mention that they can be > compiled if one wishes so -- but before I try to patch that, I'd like to > hear whether there are some non-obvious reasons why they are kept out. I am not a fan of filling the binary distribution with tools which noone will use. Perhaps the code for these could be merged into fortune itself, as options. Or perhaps the entire way for building these things could be improved even beyond that, because datfiles/Makefile is pretty disgusting.
