[OT] Why do gcc or clang don‘t have codes for compilation errors/warnings?

[Stuart Redmann]

Hello newsgroup,

Sorry for being off-topic. I just wondered why open source tools like gcc
or clang don‘t use error codes like for example MS Visual C does. If I want
to refer to a particular compilation error under VC, I can simply use its
code. For example, one of the recent threads in this group deals with
C5038. If I mention this number here everyone can just type this in his/her
favorite search engine and knows what I‘m talking about. With gcc/clang
this is much more cumbersome: I have to extract the part of the error
message that looks like it would sensible results and type this into my
search engine (simply copy-pasting might also copy names of my classes or
variables, which might give Mr. SearchEngine sensitive information about
what I‘m doing. And no, I don‘t want to use DuckDuckGo, Brian). Does anyone
else think that MS‘s error codes are a good thing?

Regards,
Stuart

[David Brown]

There are pros and cons. You've covered some of the pros of having codes.

gcc gives warning and error messages in text format. If these are
connected to optional flags, rather than always active (like syntax
errors in the code), the warning or error message gives the relevant
flag. You can refer to or search for that just as easily as for any
code from MSVC. But a key difference is that the flag has a definite
meaning - it's easy to guess what "-Wunused-function" refers to, but
impossible to guess what "C5038" might mean. (For some warning flags,
it is not always clear from the name - but it's usually quite close to
obvious.)

This also applies when specifying flags in a Makefile or other build
system. I've had very little use of MSVC, but have worked with other
compilers that deal entirely in such meaningless codes - Makefiles and
project setups are incomprehensible and unmaintainable unless they are
filled with comments, and you have to keep looking up everything.

The single real benefit, as I see it, of error codes is that they can be
easier to parse by automated tools (like an editor or IDE). gcc has
that covered too now, with options to provide messages in a
software-friendly format rather than human friendly (to the extent that
compilers and error messages are ever "friendly") messages.

No compiler I have ever used is ideal (IMHO) with regard to either flags
or messages, but on this one point, for my taste, gcc wins hands down
against MSVC.

[Öö Tiib]

On Thursday, 1 October 2020 15:30:17 UTC+3, Stuart Redmann wrote:
> Does anyone
> else think that MS‘s error codes are a good thing?

Yes, I think that:
* having error/warning code for each diagnostic is better for searching
its further elaboration in documentation or online forums and better
for whatever automatic tools.
* showing error or warning code in front of any further explaining
message (instead of after) is better for automatic tools and TL;DR
people.
* the error/warning code being some numerical or base64 garbage
(instead of terse textual) is worse for human operator and worse for
whomever who configures or scripts tools.

[Pavel]

I don't think the design choices of providing simple short errors codes
and providing readable option names or pragmas are mutually exclusive.

>
> This also applies when specifying flags in a Makefile or other build
> system. I've had very little use of MSVC, but have worked with other
> compilers that deal entirely in such meaningless codes - Makefiles and
> project setups are incomprehensible and unmaintainable unless they are
> filled with comments, and you have to keep looking up everything.
>
> The single real benefit, as I see it, of error codes is that they can be
> easier to parse by automated tools (like an editor or IDE). gcc has
> that covered too now, with options to provide messages in a
> software-friendly format rather than human friendly (to the extent that
> compilers and error messages are ever "friendly") messages.
>
> No compiler I have ever used is ideal (IMHO) with regard to either flags
> or messages, but on this one point, for my taste, gcc wins hands down
> against MSVC.
>
>

-Pavel

[Pavel]

Stuart Redmann wrote:
> Hello newsgroup,
>
> Sorry for being off-topic. I just wondered why open source tools like gcc
> or clang don‘t use error codes like for example MS Visual C does.

I think this is because it is easier for a commercial software
manufacturer to provide an efficient centralized error code allocation
system and enforce its use than for a community of gcc or clang
contributors.

If I want
> to refer to a particular compilation error under VC, I can simply use its
> code. For example, one of the recent threads in this group deals with
> C5038. If I mention this number here everyone can just type this in his/her
> favorite search engine and knows what I‘m talking about. With gcc/clang
> this is much more cumbersome: I have to extract the part of the error
> message that looks like it would sensible results and type this into my
> search engine (simply copy-pasting might also copy names of my classes or
> variables, which might give Mr. SearchEngine sensitive information about
> what I‘m doing. And no, I don‘t want to use DuckDuckGo, Brian). Does anyone
> else think that MS‘s error codes are a good thing?

I do. I also tend to think IBM's or Oracle's error codes are equally
good things :-) .

>
> Regards,
> Stuart
>

-Pavel

[Jorgen Grahn]

On Thu, 2020-10-01, Stuart Redmann wrote:
> Hello newsgroup,
>
> Sorry for being off-topic. I just wondered why open source tools like gcc
> or clang don‘t use error codes like for example MS Visual C does.

Tradition and culture. Unix was never big on cryptic error codes
(e.g. good software never prints raw errno numbers and rarely signal
numbers). MS-DOS had them and so did the Amiga; I always assumed they
originated in CP/M or something.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[David Brown]

True.

But I am not convinced that short error codes add that much when you
have named warning options, and I am not convinced it would be helpful
to have both.

[Keith Thompson]

For one thing, there isn't a one-to-one correspondence between
messages and options.

For another, MS-style error codes are language-independent. If a
user asks about an error message in French, it's difficult to search
for it; an unambiguous error code makes that easier.

I wouldn't mind if gcc added similar codes (using a distinct form that
can't be confused with Microsoft's error messages), perhaps with an
option to enable or disable them. Ideally they'd be coordinated with
clang and any other compilers that aim for gcc compatibility.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[David Brown]

I believe that there is a solid correspondence for messages that have a
related warning flag (rather than checks that are always active). But
quite possibly that correspondence could be improved.

>
> For another, MS-style error codes are language-independent. If a
> user asks about an error message in French, it's difficult to search
> for it; an unambiguous error code makes that easier.
>

The flags are language independent - they are not translated. While
it's reasonable to say it's a bit unfair to use have identifiers that
are terms in English, I don't think it helps to have identifiers that
have no meaning in /any/ language.

> I wouldn't mind if gcc added similar codes (using a distinct form that
> can't be confused with Microsoft's error messages), perhaps with an
> option to enable or disable them. Ideally they'd be coordinated with
> clang and any other compilers that aim for gcc compatibility.
>

gcc (I don't know about clang) has various options for their error
messages, including colour, position highlighting, and now JSON for
easier software parsing. It would not be unreasonable to have some kind
of numeric identifier in that kind of output (there may be one already).

I think coordination with clang here is a bit optimistic - they have
quite a few differences in their warnings and error messages. It might
be possible to get agreement on some of the messages, but there'd be
plenty of differences.

I understand that people have different opinions on this - I can only
give mine, based on personal preference and personal experience of using
compilers (not MSVC) with numeric codes for warning flags and messages.

[olcott]

Even better: A set of ISO standard error codes.

--
Copyright 2020 Pete Olcott

[Keith Thompson]

To be clear, I'm not suggesting that there *should* be a one-to-one
correspondence between messages and options. Options should, I think,
be more stable than diagnostic messages. Changing options can break
build scripts (which is why they're not localized). Diagnostic messages
are primarily intended for immediate human consumption.

I don't have specific examples, but I can imagine a command-line option
that affects multiple different diagnostic messages, which might be
split for greater precision.

>> For another, MS-style error codes are language-independent. If a
>> user asks about an error message in French, it's difficult to search
>> for it; an unambiguous error code makes that easier.
>
> The flags are language independent - they are not translated. While
> it's reasonable to say it's a bit unfair to use have identifiers that
> are terms in English, I don't think it helps to have identifiers that
> have no meaning in /any/ language.

The point is for the error codes to be searchable, not meaningful.

>> I wouldn't mind if gcc added similar codes (using a distinct form that
>> can't be confused with Microsoft's error messages), perhaps with an
>> option to enable or disable them. Ideally they'd be coordinated with
>> clang and any other compilers that aim for gcc compatibility.
>
> gcc (I don't know about clang) has various options for their error
> messages, including colour, position highlighting, and now JSON for
> easier software parsing. It would not be unreasonable to have some kind
> of numeric identifier in that kind of output (there may be one already).

On the other hand, if the option is off by default, then most users
won't enable them, which would limit their usefulness. Visual Studio,
if I'm not mistaken, always shows the unique codes. (Of course it also
shows a human-readable message in an appropriate language.)

> I think coordination with clang here is a bit optimistic - they have
> quite a few differences in their warnings and error messages. It might
> be possible to get agreement on some of the messages, but there'd be
> plenty of differences.
>
> I understand that people have different opinions on this - I can only
> give mine, based on personal preference and personal experience of using
> compilers (not MSVC) with numeric codes for warning flags and messages.

[Öö Tiib]

On Sunday, 4 October 2020 03:27:06 UTC+3, Keith Thompson wrote:
>
> The point is for the error codes to be searchable, not meaningful.

But why keep anything non-meaningful?

Meaningful codes help to understand scripts and configurations of
tools; it is same as with usage of meaningful variable names.
Our work is complicated enough to not obfuscate it with something
meaningless.

[Keith Thompson]

The idea is for each error message (which would be clearly written in
English and/or other languages) to include a unique language-indepedent
code. A hypothetical example:

c.c:2:5: error: ‘nosuchvar’ undeclared (first use in this function) [CE4527]

When a later version of gcc tweaks the wording of the body of the
message, the error code remains the same.