From: Adrien Nader <adrien@notk.org>
To: Florent Monnier <monnier.florent@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Re: portable truncate
Date: Sat, 27 Jul 2013 10:38:44 +0200 [thread overview]
Message-ID: <20130727083844.GA17235@notk.org> (raw)
In-Reply-To: <CAE1DttBWpX0ixjPXSFpkJqr8W+zxU1tedGSOJ=i2=z++SvjKVA@mail.gmail.com>
On Fri, Jul 26, 2013, Florent Monnier wrote:
> Hi,
>
> 2013/07/26, Florent Monnier wrote:
> [...]
> > 1) I thought that the module Unix only contains portable things for
> > Windows, so it's not true?
>
> This page indeed gives a list of unimplemented functions at the end:
> [1] http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual036.html
>
> but it depends which ocaml variants is used.
>
> This page above says:
> "The Cygwin port of OCaml fully implements all functions from the Unix module.
> The native Win32 ports implement a subset of them."
>
> So this page talks about 2 ocaml variants:
> - Cygwin ocaml,
> - and native Win32 ocaml.
>
> This other page, gives informations for 3 ocanl variants:
> [2] http://caml.inria.fr/ocaml/portability.en.html
>
> which are
> - native Microsoft
> - native MinGW
> - and Cygwin
>
> I should probably understand frm this that both
> "native Microsoft" and "native MinGW" are native Win32 ocaml.
Yes, they are.
> I made the error to think that native Win32 port only refers to ocaml
> compiled with MSVC, while it seems that it also include protz's ocaml
> that is a MinGW variant.
>
> I'm still not sure though that compiling with MSVC or MinGW can be
> considered equivalent.
> And actually they seem not considering this page:
> [2] http://caml.inria.fr/ocaml/portability.en.html
The compiler differs but otherwise the differences are small. The libc
that is used on Windows is Microsoft's (actually called CRT); mingw*
provide some additions to that and apparently, ftruncate is provided.
In otherlibs/win32unix/unix.ml, you have:
let ftruncate fd len = invalid_arg "Unix.ftruncate not implemented"
And in unistd.h, you have:
#ifndef FTRUNCATE_DEFINED
#define FTRUNCATE_DEFINED
/* This is defined as a real library function to allow autoconf
to verify its existence. */
#if !defined(NO_OLDNAMES) || defined(_POSIX)
int ftruncate(int, off32_t);
int ftruncate64(int, off64_t);
int truncate(const char *, off32_t);
int truncate64(const char *, off64_t);
#ifndef __CRT__NO_INLINE
__CRT_INLINE int ftruncate(int __fd, off32_t __length)
{
return _chsize (__fd, __length);
}
#endif /* !__CRT__NO_INLINE */
#else
int ftruncate(int, _off_t);
int ftruncate64(int, _off64_t);
int truncate(const char *, _off_t);
int truncate64(const char *, _off64_t);
#ifndef __CRT__NO_INLINE
__CRT_INLINE int ftruncate(int __fd, _off_t __length)
{
return _chsize (__fd, __length);
}
#endif /* !__CRT__NO_INLINE */
#endif
#endif /* FTRUNCATE_DEFINED */
Considering this, you should probably make a patch to add a file
win32unix/ftruncate.c which use the implementation above and replace the
implementation of ftruncate* in win32unix/unix.ml.
I don't know what is the purpose of the __CRT_NO_INLINE define; I've
already asked and will propagate the answer when I get it. It would be
good to have truncate*() too.
(and submit it to the bug tracker :-) )
--
Adrien Nader
next prev parent reply other threads:[~2013-07-27 8:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 10:35 [Caml-list] " Florent Monnier
2013-07-26 10:46 ` Mihamina Rakotomandimby
2013-07-26 10:48 ` Török Edwin
2013-07-26 10:52 ` Daniel Bünzli
2013-07-26 12:02 ` [Caml-list] " Florent Monnier
2013-07-27 7:05 ` David Allsopp
2013-07-27 8:54 ` Florent Monnier
2013-07-27 8:38 ` Adrien Nader [this message]
2013-07-27 9:05 ` Adrien Nader
2013-07-27 14:11 ` Florent Monnier
2013-07-27 14:23 ` Adrien Nader
2013-07-27 15:34 ` Florent Monnier
2013-07-27 15:43 ` Adrien Nader
2013-07-27 19:45 ` Florent Monnier
2013-07-27 19:53 ` Adrien Nader
2013-07-27 20:03 ` Török Edwin
[not found] ` <20130727181711.65d8456f@kiwi.local.tld>
2013-07-27 14:41 ` [Caml-list] " Florent Monnier
2013-07-27 15:26 ` Adrien Nader
2013-07-27 15:40 ` Florent Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130727083844.GA17235@notk.org \
--to=adrien@notk.org \
--cc=caml-list@inria.fr \
--cc=monnier.florent@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox