Hi,
I've been trying out the test suite.
relocatable-prog-wrapper is missing a dependency on double-slash-root.
Quite a few modules fail gnulib-tool --create-megatestdir --with-tests
with the error:
> executing automake --add-missing --copy
> Makefile.am: C objects in subdir but `AM_PROG_CC_C_O
On 10/02/2009 01:47 AM, Bruno Haible wrote:
1) Ability to look up the documentation. The next developers to maintain
this code should be able to google the function names and use the
names that are commonly in use.
While I'll drop this patch, I'll note that we _do_ use *A names when we
* lib/uname.c: Handle Windows CE and its processor types. Remove
code for processors never supported by Windows 95/98/ME. Rewrite
conversion of NT version numbers to product names.
---
Same idea as 4/5 from the previous series. 5/5 is dropped.
ChangeLog |7 +++
lib/uname.c | 162
* lib/uname.c: Assume version info is available and do big reindentation.
---
diff uses -b for readability. 1/3 + 2/3 are exactly
the same as 2/5 + 3/5 from the previous series.
ChangeLog |7 +++
lib/uname.c | 150 ++
* lib/uname.c: Use GetVersionEx, move API calls to the beginning,
try to get OSVERSIONINFOEX first and fall back to OSVERSIONINFO.
---
Same as 2/5 + 3/5 from the previous series, without assert,
without A suffix, without reindentation (left for next patch).
ChangeLog |5 ++
On 10/02/2009 02:38 AM, Bruno Haible wrote:
If you want to make a switch statement for pairs, use a macro
#define PAIR(major,minor) (((major)<<8)|(minor))
and use PAIR(5,2) etc. Then it's clear what you mean.
I'll rewrite this part to use a table.
Paolo
Paolo Bonzini wrote:
> But you do see the 5/0, 5/1, 5/2, 6/0, 6/1 pairs. I did it all but to
> save instructions. It was more readable for me.
If you want to make a switch statement for pairs, use a macro
#define PAIR(major,minor) (((major)<<8)|(minor))
and use PAIR(5,2) etc. Then it's clear
Paolo Bonzini wrote:
> I move computation of sysname towards
> the end of the function, so that the compiler can thread from one
> if to the following switch
The order of the blocks in the code was determined by the order in
the struct in sys/utsname.h:
/* Name of this node on the network. *
At the same time, Windows 95/98/ME never supported anything but 32-bit
x86, so its section can be simplified.
There is no need to "simplify" here. The goal of this uname() function is
to support all kinds of machines, even those to which we don't have
access to.
And even operating systems th
Hi Paolo,
> This further patch improves detection of Windows CE and of the processor
> kinds (ARM, SH, etc.) supported by Windows CE as well as older versions
> of Windows. I also made it return i686 for WoW64 (Win32-on-Win64).
Thanks. This is welcome.
> At the same time, Windows 95/98/ME never
On 10/02/2009 02:08 AM, Bruno Haible wrote:
Hi Paolo,
@@ -42,15 +43,20 @@ uname (struct utsname *buf)
if (gethostname (buf->nodename, sizeof (buf->nodename))< 0)
strcpy (buf->nodename, "localhost");
- /* Determine major-major Windows version. */
- version.dwOSVersionInfoSize = si
Hi Paolo,
> @@ -42,15 +43,20 @@ uname (struct utsname *buf)
>if (gethostname (buf->nodename, sizeof (buf->nodename)) < 0)
> strcpy (buf->nodename, "localhost");
>
> - /* Determine major-major Windows version. */
> - version.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
> - have_vers
Paolo Bonzini wrote:
> +#include
> + assert (have_version);
No assert please. The code which is used by end users should have the same
safety built-in than code used by developers. I therefore much prefer code
that always verifies the assertions and calls abort() (optionally with an
error m
Hi Paolo,
> This first one uses ANSI functions whenever we're passing or receiving
> strings, so that compiling with -DUNICODE succeeds. ... Ok?
I object, for the reason of maintainability of code.
1) Ability to look up the documentation. The next developers to maintain
this code should be a
Eric Blake wrote:
> According to Jim Meyering on 10/1/2009 1:59 AM:
>>> So I'm guessing that the bug was related to actual directories, where rename
>>> ("dir/","new") failed (with what errno?) while rename("dir","new")
>>> succeeded;
>>
>> That is definitely the case in question, as seen in the
>
Looks good to me. I feel like there are two reasonable sets of release
naming conventions, which convey slightly different meanings:
major minor patch
stable beta alpha
I don't suppose it's news to anyone here, but I feel compelled to
mention that the maintainers' document has al
On 10/01/2009 03:17 PM, Eric Blake wrote:
Oops - for some reason, Windows thinks it needs to revive directory "a"
once "b" is emptied out and removed. Extremely weird; unfortunately the
fix requires that renaming on top of an existing directory will be
non-atomic on cygwin. I'm debating about w
On 10/01/2009 04:54 PM, Jim Meyering wrote:
Just glancing through, some space-before-TAB sequences
jumped out at me because they were highlighted.
When changing so much, you might want to switch the affected
file to space-only indentation.
Sure. Will do so before committing.
Paolo
Paolo Bonzini wrote:
> Hi all, this is the first of a few patches to a few Win32 implementations
> of gnulib modules.
>
> This first one uses ANSI functions whenever we're passing or receiving
> strings, so that compiling with -DUNICODE succeeds. I started from the
> list of Win32 API functions, w
On Wed, Sep 30, 2009 at 7:59 PM, Bruno Haible wrote:
> - If you have multiple gnulib-generated unistd.h files and they are not
> equal, please verify that you are using different double-include
> guards in each (like you proposed yourself a couple of weeks ago).
aha! indeed, I reverted that.
ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 10/1/2009 7:17 AM:
> Here's the current state of the series, finally ready for review.
To play with it, you can use:
git pull git://repo.or.cz/gnulib/ericb.git master
- --
Don't work too hard, make some time for fun as wel
Hi all, this is the first of a few patches to a few Win32 implementations
of gnulib modules.
This first one uses ANSI functions whenever we're passing or receiving
strings, so that compiling with -DUNICODE succeeds. I started from the
list of Win32 API functions, which I got from
grep -orh '\<
This first uname cleanup switches to ANSI functions, and moves all
GetVersionEx (now GetVersionExA) calls to the beginning of the function.
This way, the calls can share one struct (OSVERSIONINFOEXA begins with
the same fields that are in OSVERSIONINFOA).
It temporarily asserts that Windows NT can
This further patch improves detection of Windows CE and of the processor
kinds (ARM, SH, etc.) supported by Windows CE as well as older versions
of Windows. I also made it return i686 for WoW64 (Win32-on-Win64).
At the same time, Windows 95/98/ME never supported anything but 32-bit
x86, so its se
This is actually a better way to organize the checks: first try
to get extended information, else fall back to OSVERSIONINFOA.
Given this, I can assert that Windows can provide version
information and proceed with the big reindentation.
* lib/uname.c: Check for OSVERSIONINFOEXA and fall back to
O
Finally a couple of tweaks. I move computation of sysname towards
the end of the function, so that the compiler can thread from one
if to the following switch (I don't know if it does, but it
looked nice...).
Also, in case this is being compiled with MSVC I do append the
version number to the una
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 9/24/2009 11:19 AM:
> The solution? ./optarg.h MUST do a split inclusion guard use of include_next
> , if the system has a native , then not bother to include
> in that case. I could played with a change to unistd.in.h t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 9/19/2009 2:04 PM:
> Here's the polished series; now pushed. I've tested on Linux, cygwin 1.5,
> cygwin 1.7, mingw, OpenBSD, Solaris 8, 9, 10.
>
> [6/12] remove: new module, for mingw and Solaris 9 bugs
> [7/12]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 10/1/2009 2:11 AM:
> Maybe I'm the only one who uses "make major"
> or who has been bothered about the semantic mismatch
> in doing so for a so-called "minor" (yet stable) release.
>
> I debated whether to keep "major" for
Maybe I'm the only one who uses "make major"
or who has been bothered about the semantic mismatch
in doing so for a so-called "minor" (yet stable) release.
I debated whether to keep "major" for a transition period,
but I don't think that would be worthwhile.
Any objection?
>From 1c233a6b61e3aca0
Eric Blake wrote:
> I'm trying to fix rename in order to implement renameat. So far, I've added
> workarounds for a Solaris 10 bug (rename("file","oops/") succeeded) and a
> Cygwin 1.5 bug (rename("hard1","hard2") reduced the link count of the hard
> linked file, such that when a later action unli
/cygdrive/c/sds/dev/current/modules/syscalls/gllib/uname.c:158: warning:
passing arg 2 of `strcpy' from incompatible pointer type
Try this:
diff --git a/lib/uname.c b/lib/uname.c
index 1eec7e2..58bb479 100644
--- a/lib/uname.c
+++ b/lib/uname.c
@@ -34,7 +34,7 @@
int
uname (struct utsname *b
32 matches
Mail list logo
