[M3devel] [M3commit] CVS Update: cm3

[Jay]

This one I can undo and still feel ok -- just push sem_t into Utypes.i3 and expose it from a common Usem.i3.
There is only one sem_t in the system.
It is global. This change just makes it usually larger and more aligned than necessary.
 
 
The danger would be if sem_t is ever embedded in something else OS-defined, or if the OS ever returned a pointer to one that Modula-3 code copied.
 
 
In general, I'm thinking either Utypes.i3 or some new Uinternal.i3 or Usysdep.i3 or Utypes.i3 + Uconstants.i3 should be where most/all system-dependent stuff.
Even existant Utypes.i3 have much redundancy -- all the ulong/ushort/int8/int16/int32/int64 types are always the same, just stuff like nlink_t, mode_t, gid_t, uid_t, off_t vary. Though imho off_t should always be INT64 or UINT64.
 
 
Usysdep.i3 seems best?
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> To: jkrell at elego.de
> Date: Mon, 29 Dec 2008 09:50:37 +1100
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> This change makes me uneasy -- do you mean to say we have a uniform
> definition of sem_t when the different targets have different
> definitions? :-O
>
> On 28 Dec 2008, at 11:03, Jay Krell wrote:
>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 08/12/28 11:03:34
>>
>> Modified files:
>> cm3/m3-libs/m3core/src/unix/Common/: m3makefile
>> cm3/m3-libs/m3core/src/unix/linux-common/: m3makefile
>> cm3/m3-libs/m3core/src/unix/openbsd-common/: m3makefile
>> Added files:
>> cm3/m3-libs/m3core/src/unix/Common/: Usem.i3
>> Removed files:
>> cm3/m3-libs/m3core/src/unix/linux-common/: Usem.i3
>> cm3/m3-libs/m3core/src/unix/openbsd-common/: Usem.i3
>>
>> Log message:
>> another common header file -- however this bought by defining sem_t
>> to have the maximum size and alignment of any system;
>> Solaris's 48 byte 64bit aligned version
>> The CM3 code base has one static sem_t in the pthread code.
>