| A rational way. As a second step I would suggest to change the
| extensions (.prev, .next, .xxx) to be allowed in head position too,
| but I'm note sure where the sandbox tag gets processed. If
| translate_tags() could take that into account, its not a big deal
| ... Where is this state
Dear cvs developers,
for cvs 1.11.19 and earlier, lib/xtime.h is included twice, which breaks
compiling on IRIX 5.3.
The following patch prevents this:
--- lib/xtime.h.orig2005-03-01 15:53:11.0 +0100
+++ lib/xtime.h 2005-03-01 15:54:20.0 +0100
@@ -12,6 +12,9 @@
* functions
Derek Price wrote:
First, I found man pages stating that valloc() was obsoleted in favor of
posix_memalign(). Does anyone have a feel for how portable
posix_memalign() is
It appears to be implemented only by glibc.
Second, if posix_memalign() is not portable, is there any interest in a
Derek Price wrote:
Why mmap?
mmap allocates the number of pages you want, without the 1/2 page lossage
on average that malloc() has.
What sort of object would you
suggest I map the allocation to? My Linux man page says that the
MAP_ANONYMOUS flag (which requires no object to map) has been
Derek Price wrote:
Why do you prefer mmap to posix_memalign?
Yes, if posix_memalign exists, it can probably be used instead of mmap.
But since the only known platform having it is glibc, and on glibc it
wastes even more memory than your simple valloc(), I would prefer raw mmap().
This simple
Georg Schwarz wrote:
I cannot judge this.
I was just following the example given in
http://cvsweb.NetBSD.org/bsdweb.cgi/src/share/misc/style?rev=H
EADcontent-type=text/x-cvsweb-markup
Oh, dear. Time to send NetBSD a note suggesting they change the example, if
they want to remain ISO/ANSI
[EMAIL PROTECTED] wrote:
Dear cvs developers,
for cvs 1.11.19 and earlier, lib/xtime.h is included twice,
which breaks
compiling on IRIX 5.3.
The following patch prevents this:
--- lib/xtime.h.orig2005-03-01 15:53:11.0 +0100
+++ lib/xtime.h 2005-03-01 15:54:20.0
Derek Price wrote:
Okay, I've implemented this as you suggested, Bruno. Installed in CVS,
it passes tests in all four modes (MMAP, MMAP/NO-MAP_ANON,
POSIX_MEMALIGN, OTHER). I've attached the patch, but I still have a few
questions.
Thanks. I've installed this into gnulib, with the following
Derek Price wrote:
| | So probably the expression used should connote this. After some
| | consideration, I would vote for '.origin' here. I disagree
| with | being meaningless. I often export a project state into a
| local | repository, work on it, and when I'm done, move the files
| back to |
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Meyering wrote:
| Here's a complete patch, minus the parts that are regenerated via
| autoreconf (which I'll check in, too, being careful to use
| automake-1.9.3, which is what generated the current Makefile.in
| files -- unless we can upgrade to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
Derek Price wrote:
| | So probably the expression used should connote this. After some
| | consideration, I would vote for '.origin' here. I disagree
| with | being meaningless. I often export a project
Derek Price wrote:
- Rename macro gl_FUNC_MMAP to gl_FUNC_MMAP_ANON to sync
with new m4 file name.
Applied, thanks.
- Remove unnecessary fd set.
You can even optimize away the 'fd' variable entirely in this case and
make it a constant.
- Comment in header says
Derek Price wrote:
Jim.Hyslop wrote:
| [EMAIL PROTECTED] wrote:
|
| Dear cvs developers,
|
| for cvs 1.11.19 and earlier, lib/xtime.h is included twice, which
| breaks compiling on IRIX 5.3. The following patch prevents this:
|
| --- lib/xtime.h.orig2005-03-01 15:53:11.0
Mark D. Baushke writes:
I have no objections to .origin being used for the very first revision
of the mainline.
Why bother with a special name? Just use .trunk.root.
-Larry Jones
Ever notice how tense grown-ups get when they're recreating? -- Calvin
Do you still see some nits that could be improved?
Oops, there was one more nit: The error messages were not internationalized.
I did this:
diff -c -3 -r1.2 pagealign_alloc.c
*** lib/pagealign_alloc.c 3 Mar 2005 16:21:00 - 1.2
--- lib/pagealign_alloc.c 3 Mar 2005 16:36:58
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Larry Jones [EMAIL PROTECTED] writes:
Mark D. Baushke writes:
I have no objections to .origin being used for the very first revision
of the mainline.
Why bother with a special name? Just use .trunk.root.
Hmmm... true enough. The .origin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
| Derek Price [EMAIL PROTECTED] writes:
|
| Derek Price wrote:
|
| | | So probably the expression used should connote this. After
| some | | consideration, I would vote for '.origin' here. I
| disagree | with | being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
| Larry Jones [EMAIL PROTECTED] writes:
|
| Mark D. Baushke writes:
|
| I have no objections to .origin being used for the very first
| revision of the mainline.
|
| Why bother with a special name? Just use .trunk.root.
|
|
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
I thought Mark was just saying earlier in this
thread that .trunk.root, by virtue of .root
normally specifying a revision on the parent
branch, should refer to the `0' revision?
Hmmm... I may be getting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
| Derek Price [EMAIL PROTECTED] writes:
|
| I thought Mark was just saying earlier in this thread that
| .trunk.root, by virtue of .root normally specifying a revision on
| the parent branch, should refer to the `0' revision?
|
|
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
| Do you still see some nits that could be improved?
|
|
| Oops, there was one more nit: The error messages were not
| internationalized. I did this:
[snip]
| *** *** 129,135 { fd = open (/dev/zero,
| O_RDONLY,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Re my earlier questions about efficiency, here's the patch using the
new pagealign_alloc module which is currently passing `make
remotecheck' here. It also contains a few modification to the new
GNULIB pagealign_alloc module because I haven't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
No. I think 0.next would be an invalid construct, or also return 0.
Yeah, you are correct.
If you take this off the trunk, this might make more sense:
BRANCH.root is on the trunk (or another branch), so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
| Therefore, I suppose that there could be a need for .origin to be
| the first revision on TRUNK
This would seldom mean much across multiple files, so I still think
.origin should not be used. The case Frank cited, where he is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
| Derek Price wrote:
|
| Should this error still be exiting (EXIT_FAILURE) when this
| function is defined to return NULL on failure?
|
|
| In this case the error is not memory exhausted, it is cannot
| open /dev/zero. This can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Price [EMAIL PROTECTED] writes:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Meyering wrote:
| Here's a complete patch, minus the parts that are regenerated via
| autoreconf (which I'll check in, too, being careful to use
|
Derek Price wrote:
It could print the error message with error (0, errno, ...) and then
return NULL. The caller could then decide if that error should be
fatal or not, as I presume they might wish to if they are calling
pagealign_alloc() as opposed to pagealign_xalloc().
Maybe... but it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello. I was looking at removing CVS's internal waitpid substitute in
favor of the GNULIB wait-process module, but it's missing one feature
I need. CVS needs to detect core dumps in the child of the server so
that the parent knows not to clean up the
Derek Price wrote:
I've attached a patch to fix a few more nits
Committed, with small wording tweaks in the comments.
- I noticed that I assumed mmap() returns NULL on error when it
actually returns MAP_FAILED according to POSIX.
Ouch, this was a major bug. Glad that you found it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
| Derek Price wrote:
|
| It could print the error message with error (0, errno, ...) and
| then return NULL. The caller could then decide if that error
| should be fatal or not, as I presume they might wish to if they
| are calling
30 matches
Mail list logo
