[ bogofilter-Patches-706375 ] Building under OS/2

[Matthias Andree]

"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
> unlocking.

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)
   unlock
   close

>>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 
> scan!

It's b0rken then. Does EMX have the program's name in argv[0]?

> 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
(non-EMX-aware) code.

>>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.

-- 
Matthias Andree