This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug preprocessor/82176] New: Feature request: replace __FILE__ with file's basename instead its full name
- From: "f.hollerer at gmx dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 11 Sep 2017 11:24:20 +0000
- Subject: [Bug preprocessor/82176] New: Feature request: replace __FILE__ with file's basename instead its full name
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176
Bug ID: 82176
Summary: Feature request: replace __FILE__ with file's basename
instead its full name
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: f.hollerer at gmx dot net
Target Milestone: ---
Actually, this is a feature request, not a bug report.
It would be great to have a command line option to tell the
preprocessor to replace __FILE__ with the basename of a file, not the
complete name with relative or absolute path components as passed to
the preprocessor / compiler when invoked.
Reason is to minimise the amount of FLASH / code memory required for
the strings.
Explanation:
I am using arm-none-eabi-gcc version 6.3.1 downloaded from
https://developer.arm.com/ to build fora Cortex-M4 with 32 kB code
memory. Unfortunately, the cmake Build system I am using always passes
the absolute file path to the compiler, furthermore the driver code
provided by the chip vendor uses allot of assert()s.
I don't want to turn off assert()s completely, but with __FILE__ being
replaced with the full file name blows up my firmware image.
Restricting it to the file's basename would bring the image back to
reasonable size, by still providing good error messages.
After consutling google for a while, I found that other compiler toolchains
provide this feature. E.g. IAR:
https://www.iar.com/support/tech-notes/general/avoiding-full-paths-in-the-output-file/
Therefore, I think it is a feature of common interest, especially in the
embedded world.
Thanks & Best regards,
Franz Hollerer