All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Marius Storm-Olsen <mstormo@gmail.com>,
	GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH v2 4/4] Add explicit Cygwin check to guard WIN32 header inclusion
Date: Tue, 10 Nov 2009 18:48:12 +0000	[thread overview]
Message-ID: <4AF9B56C.5000205@ramsay1.demon.co.uk> (raw)
In-Reply-To: <4AF7C2C6.5070307@viscovery.net>

Johannes Sixt wrote:
> Ramsay Jones schrieb:
>> Since commit 435bdf8c ("Make usage of windows.h lean and mean",
>> 16-9-2009), the amount of code potentially including the WIN32
>> API header files has greatly increased. In particular, the Cygwin
>> build is at greater risk of inadvertently including WIN32 code
>> within preprocessor sections protected by the WIN32 or _WIN32
>> macros.
> 
> Thanks, this makes the problem pretty clear that you want to solve.
> 

Hmm, OK. Note the "... potentially including ..." above.

>> The previous commit message, along with comments elsewhere, assert
>> that the WIN32 macro is not defined on Cygwin. Currently, this is
>> true for the cygwin build. However, the cygwin platform can be
>> used to develop WIN32 GUI, WIN32 console, and POSIX applications.
>> Indeed it is possible to create applications which use a mix of
>> the WIN32 API and POSIX code (eg git!).
> 
> In this paragraph, you are only saying that cygwin comes with headers and
> libraries that can be used to write code using the Windows API in addition
> to the POSIX headers and libraries. (I'm just asking, not complaining;
> perhaps this could be stated differently.)
> 

;-) The above paragraph, along with the one below, was once part of an even
larger paragraph which I had edited multiple times and, eventually, split
up. I had intended to delete the last two sentences from the above paragraph.
Whilst the content of those sentences is true, it is not necessary for them
to be there and, having been orphaned at the end of the paragraph, now sound
a bit odd.

If I were to create a version 4 of the patch, I would delete that text.

>> Unlike native WIN32 compilers, gcc on cygwin does not automatically
>> define the _WIN32 macro. However, as soon as you include the
>> <windows.h> header file, the _WIN32 and WIN32 macros are defined.
>>
>> In order to reduce the risk of problems in the future, we protect
>> the inclusion of the windows header with an explicit check for
>> __CYGWIN__. Also, we move the other use of the <windows.h> header
>> from compat/win32.h to compat/cygwin.c
> 
> But I sense a contradiction here. Above you are arguing that much more
> WIN32 code is included, but here you are saying that the explicit check
---------------^
potentially

> for __CYGWIN__ is just a safety measure to protect us from failures in
> future changes. Indeed, looking at the code it seems that this extra check
> is *currently* not necessary:

*correct*! I have not claimed otherwise.

[snipped other text I also agree with!]

> IOW, I disagree with your analysis that a lot of code suffers from
> windows.h pollution. What am I missing?

Hmm, I don't know; but the analysis that you claim for me, I don't
think is mine! :-D

Hmm, I don't have a great investment in this patch (it doesn't fix a bug
after all), so given that you don't see any merit in it, I'm more than
happy just to drop it! :-P

So, Junio, could you please drop this patch from the series.

Thanks!

ATB,
Ramsay Jones

  reply	other threads:[~2009-11-10 19:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-07 20:22 [PATCH v2 4/4] Add explicit Cygwin check to guard WIN32 header inclusion Ramsay Jones
2009-11-09  7:20 ` Johannes Sixt
2009-11-10 18:48   ` Ramsay Jones [this message]
2009-11-09 19:26 ` Ramsay Jones
2009-11-09 20:30   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AF9B56C.5000205@ramsay1.demon.co.uk \
    --to=ramsay@ramsay1.demon.co.uk \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    --cc=mstormo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.