Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001304 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2019-11-27 11:15 2024-06-11 09:08
Reporter joerg View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Jörg Schilling
Organization
User Reference
Section C99
Page Number 2543
Line Number 82297-8298
Interp Status ---
Final Accepted Text See Note: 0004833
Summary 0001304: Align c99 -o with reality, the standard should not be more restrictive than implementations
Description The text:

-o outfile
    Use the pathname outfile, instead of the default a.out, for the executable file produced. If the -o option is present with -c or -E, the result is unspecified.

Does not reflect the behavior of C-compilers since more than 35 years.

The option -o always works with sall known compiler implementations together with -c. It is important to be able to tell the compiler to directly create a named output file for a c99 -c xx.c compilation in order to avoid file clobbering with concurrent compilations that would be the result from compiling to a standard file name and then being forved to rename the output file.
Desired Action Change:

-o outfile
    Use the pathname outfile, instead of the default a.out, for the executable file produced. If the -o option is present with -c or -E, the result is unspecified.

to:

-o outfile
    Use the pathname outfile, instead of the default a.out, for the executable file produced. If the -o option is present with -E, the result is unspecified.
Tags issue8
Attached Files

- Relationships
related to 0001294Closed POSIX recognizes the existence of dynamically loadable, executable object files, but provides no way of producing them. 

-  Notes
(0004670)
geoffclare (manager)
2019-11-27 15:53

 Your claim that -o "always works with all known compiler implementations together with -c" is incorrect. It does not work with the HP-UX compiler.

Also, the requested change is both wrong and insufficient.

It is wrong because the unchanged part "the default a.out, for the executable file produced" makes no sense when -c is used.

It is insufficient because removing the statement that the behaviour is unspecified does not magically make it become specified. You need to propose additional wording to specify the behaviour, and it needs to cover these points:

1. What happens if you specify -c and -o together with more than one .c file

2. What happens if the -o option-argument specifies a directory

(With some compilers, cc -o dir -c file1.c file2.c creates dir/file1.o and dir/file2.o)
(0004671)
joerg (reporter)
2019-11-27 16:04
edited on: 2019-11-27 16:07

 Your claim about the HP-UX compiler is wrong, see the related rules in the Schily Makefilesystem that work fine on HP-UX and all other platforms that are relevant.

This even works for "cl.exe"... you just need to use -Fo instead.

Regarding finding a better wording: you are of course welcome!
(0004715)
Don Cragun (manager)
2020-01-09 17:15
edited on: 2020-01-09 17:38

 In the Options, change P2543, L82297-82298 from:

    
-o outfile
Use the pathname outfile, instead of the default a.out, for the executable file produced. If the -o option is present with -c or -E, the result is unspecified.
to:
-o outfile
Name the file produced by the link-editor outfile, instead of the default a.out. If a single object file is being produced (by using -c with a single input file), name the object file outfile instead of the default file.o. If the -o option is present with -E, the result is unspecified.

Add the following new paragraphs to Rationale after P2551, L82609:
<tt>c99 -c -o ...</tt> is frequently used to directly place the .o file into an alternative directory without a need to separately rename the output file. This helps to support concurrent compilations and out of tree builds.

Some implementations allow -c -o directory to produce directory/file.o even when there is more than one input file; however, portable applications using -c with -o must compile only one file at a time and must specify the final destination filename rather than a directory.
(0004833)
geoffclare (manager)
2020-04-30 14:31
edited on: 2020-04-30 15:08

 Reopening because the changes in Note: 0004715 clash with the -o changes in bug 0001294. Also, a needed change to the DESCRIPTION was missed.

New proposed changes...

On page 2542 line 82232 section c99, change:
If the -c option is specified, for all pathname operands
to:
If the -c option is specified and the -o option is not specified, for all pathname operands

On page 2543 line 82297-82298 section c99, after applying bug 1294 change:
Name the output file to be produced. If the -o option is present with -c or -E, the result is unspecified.
to:
Name the output file to be produced. If the -o option is present with -E, or with -c and more than one input file, the result is unspecified.

When creating a single object file (by using -c with a single input file), use the pathname outfile, instead of the default file.o, for the object file produced.

Add the following new paragraphs to Rationale after P2551, L82609:
<tt>c99 -c -o ...</tt> is frequently used to directly place the .o file into an alternative directory without a need to separately rename the output file. This helps to support concurrent compilations and out of tree builds.

Some implementations allow -c -o directory to produce directory/file.o even when there is more than one input file; however, portable applications using -c with -o must compile only one file at a time and must specify the final destination filename rather than a directory.

- Issue History
Date Modified Username Field Change
2019-11-27 11:15 joerg New Issue
2019-11-27 11:15 joerg Name => Jörg Schilling
2019-11-27 11:15 joerg Section => C99
2019-11-27 11:15 joerg Page Number => 2543
2019-11-27 11:15 joerg Line Number => 82297-8298
2019-11-27 15:53 geoffclare Note Added: 0004670
2019-11-27 16:04 joerg Note Added: 0004671
2019-11-27 16:07 joerg Note Edited: 0004671
2020-01-06 16:53 eblake Relationship added related to 0001294
2020-01-09 17:15 Don Cragun Note Added: 0004715
2020-01-09 17:19 Don Cragun Note Edited: 0004715
2020-01-09 17:25 Don Cragun Interp Status => ---
2020-01-09 17:25 Don Cragun Final Accepted Text => See Note: 0004715.
2020-01-09 17:25 Don Cragun Status New => Resolved
2020-01-09 17:25 Don Cragun Resolution Open => Accepted As Marked
2020-01-09 17:25 Don Cragun Tag Attached: issue8
2020-01-09 17:38 Don Cragun Note Edited: 0004715
2020-01-09 17:38 Don Cragun Note Edited: 0004715
2020-04-30 14:31 geoffclare Note Added: 0004833
2020-04-30 14:31 geoffclare Status Resolved => Under Review
2020-04-30 14:31 geoffclare Resolution Accepted As Marked => Reopened
2020-04-30 15:08 geoffclare Note Edited: 0004833
2020-04-30 15:21 geoffclare Final Accepted Text See Note: 0004715. => See Note: 0004833
2020-04-30 15:21 geoffclare Status Under Review => Resolved
2020-04-30 15:21 geoffclare Resolution Reopened => Accepted As Marked
2020-05-19 11:04 geoffclare Status Resolved => Applied
2024-06-11 09:08 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker