On 08/05/2009 08:13 AM, Bruno Haible wrote:
That's not a Microsoft documentation. Thus, it may break in future versions
of Windows.
This is just an optimization to avoid a system call and it is safe if it
wrongly returns false.
(BTW I found out that this is not a Wine bug and can be probably
Paolo Bonzini wrote:
> > Where have you seen a documentation of the bit patterns of handles?
> > This will not necessarily work in all implementations (Windows, Wine,
> > ReactOS).
>
> In Wine's source code and in http://www.winehq.org/docs/winedev-guide/x3500:
>
> Console handles, on the other h
Where have you seen a documentation of the bit patterns of handles?
This will not necessarily work in all implementations (Windows, Wine,
ReactOS).
In Wine's source code and in http://www.winehq.org/docs/winedev-guide/x3500:
Console handles, on the other hand, are not multiple of four, but ha
Paolo Bonzini wrote:
> #define IsHandleConsole(h) (((long) (h) & 3) == 3)
Where have you seen a documentation of the bit patterns of handles?
This will not necessarily work in all implementations (Windows, Wine,
ReactOS).
The documented way to test for a console handle is like this:
static BOOL
In GNU Smalltalk I had a bug where somehow the wineserver would start
reporting ERROR_INVALID_HANDLE for console handles after a
WaitForSingleObject. This patch works around it by not calling
WaitForSingleObject except if really necessary, which is a good idea anyway.
I also save WSAEnumNetwo
On Tue, 4 Aug 2009, Bruno Haible wrote:
> > > The only change I made was to move your new ChangeLog to the
> > > beginning of the file.
> >
> > Hmm. Sorry. Not sure how that happened.
>
> It should not happen if you are using the 'git-merge-changelog' driver
> (see installation instructions in
Joel E. Denny wrote:
> > > diff --git a/ChangeLog b/ChangeLog
> > > index ba72930..9591fdb 100644
> > > --- a/ChangeLog
> > > +++ b/ChangeLog
> > > @@ -23,6 +23,12 @@
> > >
> > > 2009-08-03 Joel E. Denny
> > >
> > > + update-copyright: support @copyright{} and ©
> > > + * build-aux/update-copyr
5. Inconsistent line prefix. In many cases, it's a C-style comment such
that "/*" appears only on the first line. In some cases, it's just
inconsistent indentation.
For better or worse, it's very common to have /* or just * preceding the
copyright line ...
The GNU maintainers documentation says:
Ah, yes, you're right, sorry. I was thinking of the paragraph I added
to gpl-howto.html on the web site:
Always use the English word “Copyright”; by international
convention, this is used worldwide, even for material in other
languages. The copyright s
On Tue, 4 Aug 2009, Karl Berry wrote:
> > Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
> with no
> > "(C)") the preferred form?
>
> It's recommended by the GNU coding standards and GNU maintainers
> documentation.
>
> The (C) is neither recommended nor
> Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
with no
> "(C)") the preferred form?
It's recommended by the GNU coding standards and GNU maintainers
documentation.
The (C) is neither recommended nor disrecommended, though I admit most
of the examples (wr
> 2. No "(C)" after "Copyright".
Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
with no "(C)") the preferred form?
It is correct (to the best of my knowledge) that the "(C)" is
insignificant. It is harmless to have it, though. It should be neither
required no
On Tue, 4 Aug 2009, Jim Meyering wrote:
> > diff --git a/ChangeLog b/ChangeLog
> > index ba72930..9591fdb 100644
> > --- a/ChangeLog
> > +++ b/ChangeLog
> > @@ -23,6 +23,12 @@
> >
> > 2009-08-03 Joel E. Denny
> >
> > + update-copyright: support @copyright{} and ©
> > + * build-aux/update-c
On Tue, 4 Aug 2009, Matthew Woehlke wrote:
> Joel E. Denny wrote:
> > I just ran update-copyright on gnulib. It warns about a long list of files.
> > There are various problems:
> >
> > 2. No "(C)" after "Copyright".
>
> Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright" wit
Joel E. Denny wrote:
> On Mon, 3 Aug 2009, Joel E. Denny wrote:
>
>> I just ran update-copyright on gnulib. It warns about a long list of
>> files. There are various problems:
>>
>> 1. "@copyright{}" or "©" instead of "(C)".
>
>> In my opinion, update-copyright should be extended to handle #1.
>
Joel E. Denny wrote:
I just ran update-copyright on gnulib. It warns about a long list of
files. There are various problems:
2. No "(C)" after "Copyright".
Given that (IIRC) "(C)" has no legal meaning, isn't this ("Copyright"
with no "(C)") the preferred form?
--
Matthew
Please do not qu
On Tue, 4 Aug 2009, Jim Meyering wrote:
> That was mistakenly on top of your change.
> Here's a clean version that also uses \015 rather than
> tr's slightly less portable \r.
>
> >From 7ef1309415c41e2a3c361a80854d3866d310a87e Mon Sep 17 00:00:00 2001
> From: Jim Meyering
> Date: Tue, 4 Aug 2009
On Tue, Aug 4, 2009 at 2:24 AM, Bruno Haible wrote:
> Sam Steingold wrote:
>> configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.
>> configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,
>> configure.in: that aclocal.m4 is present in the top-level directory,
>> c
On Tue, 4 Aug 2009, Jim Meyering wrote:
> > From f7aecbdf27eea1a0a6eb0960dbb34627ff56ccb6 Mon Sep 17 00:00:00 2001
> > From: Joel E. Denny
> > Date: Tue, 4 Aug 2009 09:37:54 -0400
> > Subject: [PATCH] update-copyright-tests: correctly test EOL=\r\n handling
> >
> > * tests/test-update-copyright.s
Jim Meyering wrote:
> Joel E. Denny wrote:
>> On Tue, 4 Aug 2009, Jim Meyering wrote:
>>
>>> Thanks for all of that.
>>> I've pushed that as well as your other three change sets,
>>> and one more change:
>>
>> Thanks. Unfortunately, my email client ate the \r\n sequences in the DOS
>> EOL test.
Joel E. Denny wrote:
> On Tue, 4 Aug 2009, Jim Meyering wrote:
>
>> Thanks for all of that.
>> I've pushed that as well as your other three change sets,
>> and one more change:
>
> Thanks. Unfortunately, my email client ate the \r\n sequences in the DOS
> EOL test. Sorry about that. The attached
On Mon, 3 Aug 2009, Joel E. Denny wrote:
> I just ran update-copyright on gnulib. It warns about a long list of
> files. There are various problems:
>
> 1. "@copyright{}" or "©" instead of "(C)".
> In my opinion, update-copyright should be extended to handle #1.
The following patch impleme
On Tue, 4 Aug 2009, Jim Meyering wrote:
> Thanks for all of that.
> I've pushed that as well as your other three change sets,
> and one more change:
Thanks. Unfortunately, my email client ate the \r\n sequences in the DOS
EOL test. Sorry about that. The attached patch adds them back.From f7ae
FYI, one more:
>From 8eda5d5ddd593f97e1ca524ef4c87d178f5c5d92 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 4 Aug 2009 11:17:08 +0200
Subject: [PATCH] maint.mk: make update-copyright exclusion list more
configurable
* top/maint.mk (update-copyright): Default to excluding COPYING,
but a
Hi Simon,
I noticed some long lines and unnecessary '&&' between statements
in the refresh-po rule so made a few changes.
I'm pretty sure I've introduced no semantic change.
>From adbc54c3a6c917941c845fccc557a83c46f130d4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 4 Aug 2009 10:22:16
Simon Josefsson wrote:
> In build-aux/update-copyright it says:
>
> # You may wish to place a target like the following in your top-level
> # makefile in your project:
> #
> # .PHONY: update-copyright
> # update-copyright:
> # if test -d .git; then \
> #
Joel E. Denny wrote:
> On Sat, 1 Aug 2009, Joel E. Denny wrote:
>
>> > No objection on principle, from me. The 'update-copyright' module
>> > works fine for me in most cases. But it has no testsuite, therefore it
>> > may surprise us.
>>
>> My test suite has mostly been coreutils and bison (plus a
27 matches
Mail list logo
