[Bug pending/64094] New: "No such file or directory" -> "No such file"

[Bug pending/64094] New: "No such file or directory" -> "No such file"

[jg at jguk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

            Bug ID: 64094
           Summary: "No such file or directory" -> "No such file"
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: pending
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jg at jguk dot org

Hello

I saw when "main.cpp" is not accessible, the standard ENOENT message "No such
file or directory" is used.

However, this is not really accurate, as it was open() that was used to open a
file. A file was expected, therefore if GCC could output "No such file" the
message would be clearer.  I objdump has this behaviour already:

$ objdump -a main2.exe
objdump: 'main2.exe': No such file



$ gcc --version
gcc (GCC) 4.8.3
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc -o main main.cpp
gcc: error: main.cpp: No such file or directory
gcc: fatal error: no input files
compilation terminated.

[Bug driver/64094] "No such file or directory" -> "No such file"

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-27
                 CC|                            |manu at gcc dot gnu.org
          Component|pending                     |driver
     Ever confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Can you figure out using GDB where the error comes from? I guess somewhere in
gcc.c.
>From gcc-bugs-return-468763-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Nov 27 12:57:34 2014
Return-Path: <gcc-bugs-return-468763-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25257 invoked by alias); 27 Nov 2014 12:57:34 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25213 invoked by uid 55); 27 Nov 2014 12:57:31 -0000
From: "ktietz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63904] ICE when accessing array member of constexpr struct
Date: Thu, 27 Nov 2014 12:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktietz at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63904-4-2Mo2VUfEb9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63904-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63904-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg03235.txt.bz2
Content-length: 402

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc904

--- Comment #2 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Author: ktietz
Date: Thu Nov 27 12:56:58 2014
New Revision: 218122

URL: https://gcc.gnu.org/viewcvs?rev!8122&root=gcc&view=rev
Log:
    PR c++/63904
    * g++.dg/cpp0x/pr63904.C: New.


Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/pr63904.C
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug driver/64094] "No such file or directory" -> "No such file"

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk <harald at gigawatt dot nl> ---
GCC uses strerror (indirectly) for printing error messages, through the use of
%m with vfprintf. This is done in many separate locations. binutils has special
cases in the form of (if ENOENT then print custom message else print system
error).

The GNU Coding Standards
(http://www.gnu.org/prep/standards/html_node/Semantics.html) say:

> Include the system error text (from perror, strerror, or equivalent) in every error message resulting from a failing system call, as well as the name of the file if any and the name of the utility.

I do not personally care either way, but GCC's error message is in line with
those coding standards, and binutils's error message is not (even if it may be
in line with the intent of those coding standards, I make no comment on that).
Perhaps either GCC should be left as it is now, or if those coding standards do
not correctly reflect the intent, they should be changed first?

[Bug driver/64094] "No such file or directory" -> "No such file"

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
"No such file or directory" is a familiar, recognizable error message, and is
automatically translated through libc.  Is the required complexity for this
special case really worth it?

[Bug driver/64094] "No such file or directory" -> "No such file"

[jg at jguk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

--- Comment #5 from Jon Grant <jg at jguk dot org> ---
Hi Manu

I like your open_strerror() propopsal. Is this how Bintuils has done it?


Note: I realise this problem stems from ENOENT being used by both opendir() and
open(). I think you only need to provide two wrappers to handle these cases

Note: %m is not ideal in my view as it is a C Library extension that I believe
is not widely supported. could it be replaced with %s?
http://www.gnu.org/software/libc/manual/html_node/Other-Output-Conversions.html


Alternatively, could have a check where files are stat() before they are
opened, and then report the error then. Likewise for directories.

[Bug driver/64094] "No such file or directory" -> "No such file"

[jg at jguk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

--- Comment #6 from Jon Grant <jg at jguk dot org> ---
Two more tests where I try to pass directories to GCC.

(1)
$ mkdir testdir

$ gcc -Wall -Werror -o main testdir
testdir: file not recognized: Is a directory
collect2: error: ld returned 1 exit status


(2)
$ mkdir testdir.cpp

$ gcc -o main testdir.cpp
cc1plus: fatal error: testdir.cpp: No such file or directory
compilation terminated.


Re (1) output reasonable. Although I don't know why it is getting all the way
to LD after the error?

Re (2) error handling not quite right, appears to have slipped through, 
because it had .cpp extension?

Perhaps each "filename" could be checked with if (stat(pathname, &sb) == 0 &&
S_ISDIR(sb.st_mode))

[Bug driver/64094] "No such file or directory" -> "No such file"

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

--- Comment #7 from Andreas Schwab <schwab@linux-m68k.org> ---
In order to be precise trying to open doesnotexist/foo.c should report "no such
directory".

[Bug driver/64094] "No such file or directory" -> "No such file"

[jg at jguk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64094

--- Comment #8 from Jon Grant <jg at jguk dot org> ---
Could add a file_check(const char * path) which checks each component of a
path. Would output:

error opening doesnotexist/foo.c: doesnotexist: No such directory