[M3devel] inconsistencies in external interfaces

Mika Nystrom mika at async.caltech.edu
Sat Apr 25 07:32:37 CEST 2009


Well, I hear you, but in this case I doubt it.  /usr/include/time.h has

struct tm *localtime __P((const time_t *));

and man localtime yields...

     struct tm *
     localtime(const time_t *clock);

It looks like a manual job to me.  

     Mika

Jay writes:
>--_7e282a72-e70c-455d-9d62-0c65873ebb2d_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>1) I THINK these files are often a pretty direct translation of /usr/includ=
>e=2C dead stuff=2C comments=2C and all. Posix often mandates that certain t=
>ypes are certain headers=2C even if they aren't used by any function in tha=
>t header.
>
>=20
>
>=20
>
>Utime.i3 would declare time_t not necessarily for its own purposes but so t=
>hat C code (nonsense example but ok):
>
>=20
>
>=20
>
>#include <time.h>
>
>=20
>
>int main()
>
>{
>
>  time_t t =3D 0=3B
>
>  /* ... */
>
>}
>
>=20
>
>=20

>translates "directly" to Modula-3 (ha):
>
>=20
>
>=20
>
>IMPORT Utime=3B
>
>VAR
>
>  t: Utime.time_t :=3D 0
>
>BEGIN
>
>  (* ... *)
>
>END Main.
>
> =20
>
>2) Almost everything in m3core/src/unix is dead anyway=2C outside of the co=
>mmon directory=2C and Usysdeps.i3=2C and the userthread support.
>
>Look at the m3makefile. It is mostly if'ed out.
>
>The only active platforms using their own full assortment of cloned /usr/in=
>clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open=
>Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN=
> must wait for additional hardware=2C or someone else to switch it (Tony?)
>
>=20
>
>=20
>
> - Jay
>
>=20
>> To: m3devel at elegosoft.com
>> Date: Fri=2C 24 Apr 2009 20:41:04 -0700
>> From: mika at async.caltech.edu
>> Subject: [M3devel] inconsistencies in external interfaces
>>=20
>>=20
>> All right=2C here's another little oddity.
>>=20
>> m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the following:
>>=20
>> time_t =3D int=3B (* seconds since the Epoch *)
>>=20
>> ...
>>=20
>> <*EXTERNAL*> PROCEDURE localtime (clock: long_star): struct_tm_star=3B
>>=20
>> Huh? What's the point of declaring time_t if you're not going to
>> use it?
>>=20
>> (I think it used to be that long_star and time_t resolved to the
>> same type=2C before the LONGINT work or some other foreign interface
>> updating=2C but they no longer seem to...)
>>=20
>> Mika
>>=20
>>=20
>
>--_7e282a72-e70c-455d-9d62-0c65873ebb2d_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Verdana
>}
></style>
></head>
><body class=3D'hmmessage'>
>1) I THINK these files are often a pretty direct&nbsp=3Btranslation of /usr=
>/include=2C dead stuff=2C comments=2C and all. Posix often mandates that ce=
>rtain types are certain headers=2C even if they aren't used by any function=
> in that header.<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>Utime.i3 would&nbsp=3Bdeclare time_t not necessarily for its own purposes b=
>ut so that C code (nonsense example but ok):<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>#include &lt=3Btime.h&gt=3B<BR>
>&nbsp=3B<BR>
>int main()<BR>
>{<BR>
>&nbsp=3B&nbsp=3Btime_t t =3D 0=3B<BR>
>&nbsp=3B /* ... */<BR>
>}<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>translates "directly" to Modula-3 (ha):<BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>IMPORT Utime=3B<BR>
>VAR<BR>
>&nbsp=3B t: Utime.time_t&nbsp=3B:=3D 0<BR>
>BEGIN<BR>
>&nbsp=3B (* ... *)<BR>
>END Main.<BR>
>&nbsp=3B <BR><BR>2) Almost everything in m3core/src/unix is dead anyway=2C =
>outside of the common directory=2C and Usysdeps.i3=2C and the userthread su=
>pport.<BR>
>Look at the m3makefile. It is mostly if'ed out.<BR>
>The only active platforms using their own full assortment of cloned /usr/in=
>clude are I386_DARWIN and AMD64_DARWIN..until I get around to them. If Open=
>Darwin/x86 7.0 will run in a VM=2C I386_DARWIN will fall soon. AMD64_DARWIN=
> must wait for additional hardware=2C or someone else to switch it (Tony?)<=
>BR>
>&nbsp=3B<BR>
>&nbsp=3B<BR>
>&nbsp=3B- Jay<BR><BR>&nbsp=3B<BR>&gt=3B To: m3devel at elegosoft.com<BR>&gt=3B=
> Date: Fri=2C 24 Apr 2009 20:41:04 -0700<BR>&gt=3B From: mika at async.caltech=
>.edu<BR>&gt=3B Subject: [M3devel] inconsistencies in external interfaces<BR=
>>&gt=3B <BR>&gt=3B <BR>&gt=3B All right=2C here's another little oddity.<BR=
>>&gt=3B <BR>&gt=3B m3-libs/m3core/src/unix/freebsd-4/Utime.i3 has the follo=
>wing:<BR>&gt=3B <BR>&gt=3B time_t =3D int=3B (* seconds since the Epoch *)<=
>BR>&gt=3B <BR>&gt=3B ...<BR>&gt=3B <BR>&gt=3B &lt=3B*EXTERNAL*&gt=3B PROCED=
>URE localtime (clock: long_star): struct_tm_star=3B<BR>&gt=3B <BR>&gt=3B Hu=
>h? What's the point of declaring time_t if you're not going to<BR>&gt=3B us=
>e it?<BR>&gt=3B <BR>&gt=3B (I think it used to be that long_star and time_t=
> resolved to the<BR>&gt=3B same type=2C before the LONGINT work or some oth=
>er foreign interface<BR>&gt=3B updating=2C but they no longer seem to...)<B=
>R>&gt=3B <BR>&gt=3B Mika<BR>&gt=3B <BR>&gt=3B <BR></body>
></html>=
>
>--_7e282a72-e70c-455d-9d62-0c65873ebb2d_--



More information about the M3devel mailing list