On 07/25/11 18:25, Bruno Haible wrote:
> New module Used by
>
> creat fcntl-safer
> fgetpos -
> fsetpos -
> fstat acl, chdir-safer, chown, copy-file,
> fchd
On 07/25/11 17:51, Bruno Haible wrote:
> For me, that sounds perfectly in line with the gnulib approach: We create
> a new module when we notice and fix the first portability problem with
> the particular function.
It's not always that simple, unfortunately. Sometimes it's better to
think of a m
Hi Paul,
> 2) Modules which do not yet exist.
Here are the proposed new modules.
New module Used by
creat fcntl-safer
fgetpos -
fsetpos -
fstat acl, chdir
Hi Paul,
> > If you are adding a dependency to these modules, it sounds like
> > every piece of application code that somehow deads with files
> > via or would need a dependency to
> > 'largefile'?
>
> That's too strong.
I apologize. No offense was intended; just the heuristic
avoided.
. utimecmp has lib/utimecmp.c, which invokes 'lstat' and 'stat'. The
former is listed as a dependency but might be avoided, and the latter
is not listed.
. utimens has lib/utimens.c, which invokes fstat, lstat and stat.
Only lstat is listed as
Hi Paul,
> This one affects many modules, so I haven't pushed it yet.
> The basic idea is that code that uses 'stat (...)' etc.
> should always use AC_SYS_LARGEFILE, so that it doesn't
> mess up with large files. Plus, the code should use the
> up-to-date AC_SYS_LARGEFILE.
I agree with the reason
This one affects many modules, so I haven't pushed it yet.
The basic idea is that code that uses 'stat (...)' etc.
should always use AC_SYS_LARGEFILE, so that it doesn't
mess up with large files. Plus, the code should use the
up-to-date AC_SYS_LARGEFILE.
* m4/mkstemp.m4 (gl_FUNC_MKSTEMP):
* m4/te
