0000667: Add handling of .i files to c99 (c11) in Issue 8

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Category

Severity

Type

Date Submitted

Last Update

0000667

[1003.1(2008)/Issue 7] Shell and Utilities

Comment

Omission

2013-03-08 12:24

2024-06-11 08:52

Reporter

geoffclare

View Status

public

Assigned To

ajosey

Priority

normal

Resolution

Accepted

Status

Closed

Name

Geoff Clare

Organization

The Open Group

User Reference

Section

c99

Page Number

2490

Line Number

79613

Interp Status

---

Final Accepted Text

see Desired Action

Summary

0000667: Add handling of .i files to c99 (c11) in Issue 8

Description

During 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 Action

In 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

Tags

issue8

Attached Files

Relationships

child of

0000650

Closed

ajosey

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

Notes
(0001491) eblake (manager) 2013-03-14 15:32	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

Mantis 1.1.6[^]