WG15 Defect Report Ref: 9945-2-69
Topic: patch -D

This is an approved interpretation of 9945-2:1993.


Last update: 1997-05-20



	Topic:			patch -D
	Relevant Sections:	5.22

Defect Report:

	Date: Mon, 25 Jul 1994 15:00:03 -0700
	From: Fred Zlotnick <fred@mindcraft.com>  

I would like to an request official, binding interpretation from the
WG15 concerning the following point in ISO/IEC 9945-2:1993 (POSIX.2).

POSIX.2 Subclause 5.22 specifies the semantics of the "patch" utility.
In subclause 5.22.3 the behavior of the -D option is specified as

	-D <define>	Mark changes with the C preprocessor construct:

				#ifdef <define>

			The option-argument <define> shall be used as the
			differentiating symbol.

Can a conforming implementation of the patch utility use "#ifndef" to
mark changes that constitute deletions from the original file?  Can an
implementation freely choose to use #ifdef or #ifndef when either is
correct (i.e. gives a file that, after preprocessing, has the correct
contents)?  For example, the files

	#ifdef uppercase


	#ifndef uppercase

are equivalent in this sense.  Are both valid output files from a call
to a conforming "patch -D uppercase ..."?

Note that the use of #ifndef is historical practice.  Note also that if
it is not permitted, implementations can still conform, but only
through the use of such clumsy constructs as

	#ifdef <define>

In a similar vein: can a conforming implementation of "patch" use
the construct

	#if defined(<define>)

rather than

	#ifdef <define>

In general, how broadly can the phrase "the C preprocessor
construct:..." be interpreted?

Thank you for your attention to this matter.

WG15 response for 9945-2:1993 

The standard states the behaviour for #ifdef and #endif and conforming
implementations must conform to this.  The standard makes no restrictions
for the use of further C preprocessor directives between #ifdef and #endif. 
The standard does not allow using #ifndef and #if defined in the manner
specified in the interpretation request.  Concerns about this are being
refered to the sponsor.

Rationale for Interpretation:

Forwarded to Interpretations group: 26 Jul 94

Proposed resolution sent for review: 19th Nov 94
Resolved: 10th Dec 94