msync on Hurd, dev_t on MIPS

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> The Debian build of INN 2.5.1 on Hurd gives a few warnings (which do not
> prevent the package from being successfully compiled):

> storage/libstorage.a(cnfs.o): In function `CNFSflushhead':
> storage/cnfs/cnfs.c:214: warning: warning: msync is not implemented and will always fail

I wonder if MMAP_NEEDS_MSYNC or MMAP_MISSES_WRITES are defined on Hurd.
If so, this error message means that there will probably be some data
corruption if someone runs innd on the Hurd.

> storage/libstorage.a(shmem.o): In function `smcReleaseExclusiveLock':
> storage/buffindexed/shmem.c:130: warning: warning: semop is not implemented and will always fail
> storage/libstorage.a(shmem.o): In function `smcGetSemaphore':
> storage/buffindexed/shmem.c:29: warning: warning: semget is not implemented and will always fail
> storage/libstorage.a(shmem.o): In function `smcCreateSemaphore':
> storage/buffindexed/shmem.c:62: warning: warning: semctl is not implemented and will always fail

Nothing we can do about the latter; it implies that Hurd just doesn't have
SysV shared memory.  I think buffindexed now requires it.

> On MIPS, we have:

> hisv6/hisv6.c: In function 'hisv6_closefiles':
> hisv6/hisv6.c:272: warning: large integer implicitly truncated to unsigned type
> hisv6/hisv6.c: In function 'hisv6_new':
> hisv6/hisv6.c:480: warning: large integer implicitly truncated to unsigned type

> It corresponds to the cast to dev_t:
>    h->st.st_dev = (dev_t)-1;

> How can we change that?

That's an odd one.  I'm not sure what to make of that error.  It sounds
almost like st_dev isn't a dev_t, but that doesn't make any sense to me.
You should be able to cast -1 to an unsigned type; that's a common C
idiom.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.