[ bogofilter-Patches-706375 ] Building under OS/2
matthias.andree at gmx.de
Wed Apr 2 04:56:25 EST 2003
"Yuri Dario" <warp at os2power.com> writes:
>>1. the file must not be unlocked before the BerkeleyDB cache
>>has been flushed. If you do that, you're heading for
>>corruption (which is the likely reason for t.lock2 failure).
> here I need to do more work, but t.lock2 was failing also before
Hum. The options we have are:
#1 have the OS implicitly kill the lock on closing the file.
(we're doing that currently)
#2 db_flush() (or call the sync method manually)
>>3. We should not introduce OS-specific comments into regular
>>files, but encapsulate the portability code (such as the EMX
>>locking code) in separate files, such as a generic_lock.c or
> let me know your preferred layout, and I will rewrite the code.
I'd thought we could write a pair of functions that lock or unlock a
file, the unix implementation would use fcntl as it does now, the EMX
implementation uses the native OS/2 lock.
>>4a. GNU libc (Linux's most common libc) documents on the
>>topic of "optind": "The initial value of this variable is
>>`1'." FreeBSD documents "The variable opterr and optind are
> that's ok also for EMX; the only difference is that emx getopt() requires 0 to make the second
It's b0rken then. Does EMX have the program's name in argv?
> This could be put inside a #ifdef
I'd prefer a reset_getopt() function for that. It would reset optind and
opterr to 1 for Linux and Solaris, additionally set optreset to 1 for
some BSDs and set optind to 0 for EMX.
>>6. ignoring CR should not happen in fgetsl() -- fgets()
>>doesn't do that either. If we need a function that ignores
>>CR, then it needs to wrap around fgetsl() instead.
> that's ok for me; I put it into fgetsl() because I didn't know the
> whole logic around reading.
NP. Was there any breakage without stripping the CR? If so, we should
have a second look, to avoid bugs slipping through in the original
>>7. I suggest that the _fsetmode EMX stuff moves into a
>>separate function emx_init() or something, and a
>>os_spec_init() function that calls it.
> should I place os_spec_init() inside main or somewhere else?
Yes, the call would have to be early in main(), yes. The function itself
could go into a system.c file.
More information about the Bogofilter-dev