View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00006671003.1(2008)/Issue 7Shell and Utilitiespublic2013-03-08 12:242024-06-11 08:52
Reportergeoffclare Assigned Toajosey  
PrioritynormalSeverityCommentTypeOmission
Status ClosedResolutionAccepted 
NameGeoff Clare
OrganizationThe Open Group
User Reference
Sectionc99
Page Number2490
Line Number79613
Interp Status---
Final Accepted Textsee Desired Action
Summary0000667: Add handling of .i files to c99 (c11) in Issue 8
DescriptionDuring discussion of 0000650 it was felt that c99 would benefit from
the addition of a requirement to handle .i files (produced by c99 -E)
as per existing practice, since there is no requirement that the
output of c99 -E can be fed back to c99 as a .c file (nor should there
be), and thus no way to perform the preprocessing separately from the
subsequent compilation stages if desired.

Since the correction needed for the #pragma issue identified in
0000650 is small and can be done in TC2, I am submitting the
additional changes to add .i handling in a separate bug targeted
at Issue 8.
Desired ActionIn Issue 8 make the following changes before doing the edits to
convert the c99 utility to a c11 utility.

At page 2488 line 79540 section c99 change:

    If the -c option is specified, for all pathname operands of the
    form file.c, the files:

    $(basename pathname .c).o

    shall be created as the result of successful compilation. If the
    -c option is not specified, it is unspecified whether such .o
    files are created or deleted for the file.c operands.

to:

    If the -c option is specified, for all pathname operands of the
    form file.c or file.i, the files:

    $(basename -- pathname .c).o

    or

    $(basename -- pathname .i).o

    respectively shall be created as the result of successful
    compilation. If the -c option is not specified, it is unspecified
    whether such .o files are created or deleted for the file.c and
    file.i operands.

At page 2488 line 79560 section c99 append to the -c description:

    The application shall ensure that all operands are of the
    form file.c or file.i.

At page 2490 line 79613 section c99 change:
    file.c   A C-language source file to be compiled and optionally
             linked. The application shall ensure that the operand is
             of this form if the -c option is used.

to:
    file.c   A C-language source file to be compiled and optionally
             linked.
             
    file.i   A text file containing the output of c99 -E, to be
             compiled and optionally linked.  The processing already
             performed by c99 -E when the file was produced shall not
             be repeated when the file is compiled.


At page 2490 line 79625 section c99 in the INPUT FILES section change:

    a text file containing a C-language source program, an object file
    in the format produced by c99 -c, or

to:

    a text file containing C-language source code, a text file
    containing the output of c99 -E, an object file in the format
    produced by c99 -c, or

At page 2490 line 79649 section c99 in the STDOUT section change:

    If more than one pathname operand ending in .c (or possibly other
    unspecified suffixes) is given

to:

    If more than one pathname operand ending in .c or .i (or possibly
    other unspecified suffixes) is given

At page 2491 line 79659 section c99 in the STDERR section change:

    The standard error shall be used only for diagnostic messages. If
    more than one pathname operand ending in .c (or possibly other
    unspecified suffixes) is given

to:

    The standard error shall be used only for diagnostic messages, except
    that if more than one pathname operand ending in .c or .i (or possibly
    other unspecified suffixes) is given

At page 2495 line 79839 section c99 add to the end of example 1:

    The following usage example preprocesses foo.c and bar.c to create
    foo.i and bar.i, compiles foo.i and bar.i to create foo.o and bar.o,
    then links foo.o and bar.o to create the executable file foobar.
    Each c99 execution would ideally be invoked from a separate rule
    in a makefile (see [xref to make]) with suitable dependencies so
    that each is only executed when it needs to be:

    c99 -E foo.c > foo.i
    c99 -E bar.c > bar.i
    c99 -c foo.i
    c99 -c bar.i
    c99 -o foobar foo.o bar.o
Tagsissue8

Relationships

child of 0000650 Closedajosey c99 -E option fails to define "expanding all preprocessor directives" w.r.t. #pragma 

Activities

eblake

2013-03-14 15:32

manager   bugnote:0001491

During the 14 Mar 2013 meeting, the question was raised whether 'make' should add handling for .i files. The consensus was that while some existing implementations of make already have such handling, the use of .i files is not common enough to need a requirement.

Issue History

Date Modified Username Field Change
2013-03-08 12:24 geoffclare New Issue
2013-03-08 12:24 geoffclare Status New => Under Review
2013-03-08 12:24 geoffclare Assigned To => ajosey
2013-03-08 12:24 geoffclare Name => Geoff Clare
2013-03-08 12:24 geoffclare Organization => The Open Group
2013-03-08 12:24 geoffclare Section => c99
2013-03-08 12:24 geoffclare Page Number => 2490
2013-03-08 12:24 geoffclare Line Number => 79613
2013-03-08 12:24 geoffclare Interp Status => ---
2013-03-08 12:25 geoffclare Relationship added child of 0000650
2013-03-14 15:32 eblake Note Added: 0001491
2013-03-14 15:43 eblake Final Accepted Text => see Desired Action
2013-03-14 15:43 eblake Status Under Review => Resolved
2013-03-14 15:43 eblake Resolution Open => Accepted
2013-03-14 15:43 eblake Desired Action Updated
2013-03-14 15:44 Don Cragun Tag Attached: issue8
2020-03-24 15:46 geoffclare Status Resolved => Applied
2024-06-11 08:52 agadmin Status Applied => Closed