[M3commit] CVS Update: cm3
Jay
jay.krell at cornell.edu
Sun Jan 4 09:35:40 CET 2009
Exactly how?
Like off_t == word?
That isn't right.
Switch which files?
I want to reduce switching more than what is needed.
Can the string in an extern be "forwarded"?
That would be the ideal granularity here.
Darwin does stuff very similar or maybe the same as I am doing -- wrapper functions in C for reasons related to off_t, though the wrappers are a bit dubious, e.g.:
int m3_pread(int d, void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pread(d, buf, nbytes, offset);}
int m3_profil(char *samples, size_t size, u_long offset, u_int scale){ off_t off = (off_t)offset; return profil(samples, size, offset, scale);}
int m3_pwrite(int d, const void *buf, size_t nbytes, int offset){ off_t off = (off_t)offset; return pwrite(d, buf, nbytes, offset);}
int m3_ftruncate(int fd, int length){ off_t len = (off_t) length; return ftruncate(fd, length);}
What does the first line of each of those accomplish?
voidm3_assignOffT (off_t* dest, long src){ *dest = (off_t)src;}
Is that widening or narrowing, and if it is narrowing, silent truncation?
Granted, Modula-3 doesn't check for integer overflow anyway, so silent truncation I guess is "ok".
Ideally, every system would have a 64 bit off_t, if not the default, at least via #defines, or using function names with "64" appended (or both). The case for 32bit off_t would be interop with existing code. Otherwise, it seems clear that it should always, if possible, be 64 bits. time_t should be 64 bits too, but that's another matter.
I did just check and DJGPP seems limited to 32bit off_t.
So eventually it might have to go back to Usysdep.i3, but ok.
- Jay
From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Sun, 4 Jan 2009 15:54:48 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3Why not just switch between 32-bit and 64-bit versions.
Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484
On 4 Jan 2009, at 13:22, Jay wrote:
But how about if we always #define _FILE_OFFSET_BITS 64 and use C wrappers?
As I have done.
Or externs with "64" appended, but that prevents me from using one set of .i3 files.
I mean, I know there are "modes" with 32 bit off_t, but we should really strive not to use them, if given a choice, eh?
You think there are any systems we will ever care about that don't offer a 64 bit off_t (or off64_t, or whatever).
- Jay
From: hosking at To: jkrell at Date: Sun, 4 Jan 2009 12:57:28 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3On some platforms off_t is not 64 bits. This from Solaris (see off_t==long):
#if defined(_LARGEFILE_SOURCE) || defined(_XPG5)
#ifndef _OFF_T
#define _OFF_T
#if defined(_LP64) || _FILE_OFFSET_BITS == 32
typedef long off_t;
#else
typedef __longlong_t off_t;
#endif
#ifdef _LARGEFILE64_SOURCE
#ifdef _LP64
typedef off_t off64_t;
#else
typedef __longlong_t off64_t;
#endif
#endif /* _LARGEFILE64_SOURCE */
#endif /* _OFF_T */
#endif /* _LARGEFILE_SOURCE *
Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484
On 4 Jan 2009, at 01:53, Jay Krell wrote:
CVSROOT: /usr/cvsChanges by: jkrell at birch. 09/01/04 01:53:03Modified files:cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utypes.i3 cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 Log message:significant reduction in sysdep contentoff_t is always 64 bits (or at least let's hope so)the dir/stat flags are mostly all the same,except for a few that are zero on cygwinM[RWX][OWNER GROUP OTHER][FXWR]_OKF_SETFD, F_GETFL, F_SETFLFIONREADITIMER_REALITIMER_VIRTUALSome of this might be by chance and not by-standard,so under review for new platforms, and probably should be verifiedduring native builds.note that OS/2 has a different S_IFMT but not quite relevant here
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090104/2aa9c3fb/attachment-0002.html>
More information about the M3commit
mailing list