On 02.12.2018 16:15, Rhialto wrote:
> (let me put my devil's advocate hat on)
>
> On Sat 01 Dec 2018 at 22:14:40 +0100, Kamil Rytarowski wrote:
>> According to C++ papers, __func__ is an implementation-defined string.
>
> (in C++14, it's in 8.1.4.8)
>
> And therefore, users can't depend on any particular value.
>
>> However the current version causes a mismatch between NetBSD and the world:
>
> NetBSD:
>> $ ./a.out
>> int main(int, char **)
>
> others:
>> $ ./a.out
>> main
>
>> While both versions are compliant with C++11, this causes unnecessary
>> difference in regression tests, in particular in the LLVM project.
>
> I would argue that if the LLVM project depends on any particular value
> of __func__, they are wrong.
>
> The value that is provided by NetBSD is more useful. In C++, "main"
> isn't terribly useful information; it doesn't tell you if you're in "int
> main(int, char **)" or perhaps in "void main(char *, float)", which is a
> totally different function.
>
> I see no point in reducing our value if we're in compliance with the
> Standard and some other part of the world is not.
>
> (devil's advocate hat off)
>
> Current drafts seem to have the same wording as in older Standards, so
> this gives us no guidance about what the C++ committee thought:
>
> The function-local predefined variable \tcode{__func__} is
> defined as if a definition of the form
> \begin{codeblock}
> static const char __func__[] = "@\placeholder{function-name}@";
> \end{codeblock}
> had been provided, where \tcode{\placeholder{function-name}} is an
> \impldef{string resulting
> from \mname{func}} string.
>
> (source: https://github.com/cplusplus/draft.git )
> (\impldef{string resulting from \mname{func}} is the index entry:
> "string resulting from __func__")
>
For those who need/want decorated function name, there is still a
fallback to __PRETTY_FUNCTION__. It's used in various open-source
projects [1].
If we want this value by default, I would argue to do it on the level of
patching the compiler, rather than mutating its behavior with macros.
I've checked that 8cc, tcc, icc, gcc, clang, pcc, sdcc support __func__
so we could drop the fallback entirely and rely on compiler extension
for pre-c99 and pre-c++11 code.This feature is supported virtually by
any compiler capable to use our system headers (and not all of the
mentioned ones above are capable to do so). It's a question whether to
pretend to keep support for early versions of GCC 2.x.
[1] https://codesearch.debian.net/search?q=__PRETTY_FUNCTION__&perpkg=1
> -Olaf.
>
Attachment:
signature.asc
Description: OpenPGP digital signature