Tanguy LE CARROUR, le Tue 07 Feb 2012 11:02:34 +0100, a écrit :
> 2012/2/7 Samuel Thibault :
> > Tanguy LE CARROUR, le Tue 07 Feb 2012 10:13:05 +0100, a écrit :
> > Worse than that it won't work on GNU/Hurd because the info that memstat
> > needs is not in /proc. So it's probably not worth trying t
Hi,
2012/2/7 Samuel Thibault :
> Tanguy LE CARROUR, le Tue 07 Feb 2012 10:13:05 +0100, a écrit :
> Worse than that it won't work on GNU/Hurd because the info that memstat
> needs is not in /proc. So it's probably not worth trying to fix it.
I was expecting something like that... questions are:
1
Tanguy LE CARROUR, le Tue 07 Feb 2012 10:13:05 +0100, a écrit :
> BUT, the output is still slightly different! I guess it's normal as
> memstat scans its own memory allocation and the 2 exe don't allocate
> memory the same way!
Worse than that it won't work on GNU/Hurd because the info that memsta
Hi!
2012/2/4 Jeremie Koenig :
> > The problem is due to lstat() always returning a null size on Linux for
> /proc/*/exe, so the approach described in readlink(2) cannot be applied.
> You will need a reallocation loop similar to what you did for get_line().
Thanks for the advice! I've added a read
Source: memstat
Version: 0.9
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
X-DebBugs-CC: debian-hurd@lists.debian.org
Hi,
This patch solves the build problems for GNU/Hurd due to PATH_MAX
issues. The solution is to make dynamic string allocations instead of
usi
Hi!
Thanks for those comments!
I fixed all the trivial stuff but I still have some questions...
2012/1/26 Guillem Jover :
> [ Two requests, could you disable HTML mail in your client? And could
> you check it properly sets the MIME type for the attachments,
> otherwise other mailers will not in
Hi!
[ Two requests, could you disable HTML mail in your client? And could
you check it properly sets the MIME type for the attachments,
otherwise other mailers will not inline them on replies for example.
Thanks! ]
On Wed, 2012-01-25 at 14:01:35 +0100, Tanguy LE CARROUR wrote:
> I've remove
2012/1/25 Jérémie Koenig
> Since BUFSIZ has been in POSIX (and, I beleive, the C standards) for
> ages, it should be okay to use it as-is.
>
I've removed the "#ifndef BUFSIZ".
I've also re-indented the get_line() signature: remove one line-break and
one space.
Tanguy
fix_FTBFS4Hurd.patch
Descr
2012/1/25 Tanguy LE CARROUR :
> If it's in POSIX (any version?) we can use it without testing for its
> existance, is that it?!
It's all relative to the target architectures for the software you're
working on. But basically, yes, POSIX is the generally accepted
standard.
Since BUFSIZ has been in
On Wed, Jan 25, 2012 at 10:33 AM, Tanguy LE CARROUR
wrote:
> FIXME:
> Is it really useful to check if BUFSIZ is difined?
No, here's the reference:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.html
[More complete reply later]
--
Jérémie Koenig
http://jk.fr.eu.org/
--
To U
Source: memstat
Version: 0.9
Severity: important
Tags: patch
User: debian-hurd@lists.debian.org
Usertags: hurd
Hi,
This patch solves the build problems for GNU/Hurd due to PATH_MAX
issues. The solution is to make dynamic string allocations instead of
using fixed length buffers. The patch involves
11 matches
Mail list logo
