Hi,
Attached is a patch that fixes canonicalize_file_name for mingw.
I realise that it doesn't go so far as to stat each component,
so there is room for improvement. The original is useless for
mingw, and this patch makes guile happy.
Greetings,
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond
building guile 1.9 and sent the attached
patch and suggestion to revert back to AC_CHECK_LIB
Greetings,
Jan
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
>From 4aeb4bb48423d87001b598030afed0a2dc03e747 Mon Sep 17
o see how thorough you are, even though I still think
this is not much of a change as much as a first implementation.
See attached, greetings,
Jan
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
>From 450181944
Hi,
See attached, please apply.
Greetings,
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
>From 98e49aefe607b2df4aa23401f219507b515a93f6 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Fri, 4
I'm also attaching mingw-putenv.c which makes it easy to see that
the putenv that mingw provides does not suffer from this problem.
I haven't investigated whether it's environment or putenv which is
broken.
Greetings,
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilyp
From: Jan Nieuwenhuizen
2011-02-25 Jan Nieuwenhuizen
* lib/canonicalize-lgpl.c (__realpath)[WINDOWS]: Add an
implementation for Mingw to pass newly added tests.
* tests/test-canonicalize-lgpl.c (main)[WINDOWS]: Add test cases
for Mingw, checking basic sanity
e much
benefit in cluttering the code with DIRSEP or / or \ checks.
> > +ASSERT (result != NULL);
>
> Where are you freeing result? It's wise to avoid memory leaks, even in
> simple tests.
Ah, I'm often rather sloppy in tests. It is of course nice if tests
show how to use the code. Fixed.
Next thing is to get gnulib's putenv implementation for MinGW looked
at aend fixed (is there a reason not to drop gnulib's putenv entirely,
that fixes it for me?) and Guile 2.0.1 will be ready for
MinGW/Windows!
Thanks for your detailed review,
Greetings,
Jan.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl
From: Jan Nieuwenhuizen
2011-02-25 Jan Nieuwenhuizen
* tests/macros.h (GL_RM_RF): New macro: fallback for `rm -rf'.
* tests/test-*.c: Use it.
---
ChangeLog |5 +
tests/macros.h |8
tests/test-areadlink-with-s
From: Jan Nieuwenhuizen
2011-02-25 Jan Nieuwenhuizen
* lib/canonicalize-lgpl.c (__realpath): Rename rpath to rname, as
per GNU coding standards for file name variables.
---
ChangeLog |5 +++
lib/canonicalize-lgpl.c | 70
Any ideas on this? If you can point me to the code how to
avoid using putenv on MinGW, i.e., avoid using some module on
some platform, I'd be glad to whip up a patch?
Greetings,
Jan
Jan Nieuwenhuizen schreef op vr 04-02-2011 om 22:27 [+0100]:
> Hi,
>
> When gnulib's putenv
e (*p)
+{
+ if (ISSLASH (*p))
+*p = '/';
+ p++;
+}
+#endif
dest = __rawmemchr (rname, '\0');
start = name;
prefix_len = FILE_SYSTEM_PREFIX_LEN (rname);
}
else
{
+#if __MINGW32__
+ if (HAS_DEVICE (rname))
+
est-canonicalize-lgpl.c
@@ -279,6 +279,18 @@ main (void)
free (result2);
}
+#if __MINGW32__
+ /* Check that \\ are changed into / and casing is canonicalized. */
+ {
+int fd = creat (BASE "/MinGW", 0600);
+ ASSERT (0 <= fd);
+ASSERT (close (fd) == 0);
+
+char *resul
Paul Eggert writes:
> On 12/10/21 04:06, Jan Nieuwenhuizen wrote:
>> (thanks to your input on my previous patch, we discussed and decided not
>> to do case folding in our client code either).
>
> That patch still tries to case-fold one-letter drive specs, though -
> why
Paul Eggert writes:
> On 12/9/21 22:59, Jan Nieuwenhuizen wrote:
>> We are using the canonical form as an automatic include guard, to not
>> include the same file twice.
>
> Gnulib's same-inode module is often a better way to attack that problem.
That's an interes
Bruno Haible writes:
Hello!
> Jan Nieuwenhuizen wrote:
>> Do you see a cheap way to return the correct casing for the rest of the
>> file name?
>
> No. [1]
Check, thanks.
>> I agree it's quite debatable and a bit arbitrary to correct drive name
>> casing.
Bruno Haible writes:
Hi!
> Jan Nieuwenhuizen wrote:
>> Yes, but this example shows the mixing of three problems:
>> (1) wrong drive letter casing,
>> (2) difference in type of slash,
>> (3) difference in casing of the file name.
Please find attached a pat
16 matches
Mail list logo