[Bug 29845] New: reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

Bug #: 29845
           Summary: reserved identifier violation
           Product: Wine
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

I suggest to try the search pattern "<_(?:(?:_(.*))|([A-Z]+))" on source
files. A couple of places will be found where names begin with two underscores
or an underscore and an uppercase letter.

Examples:
- __WINE_ACCCTRL_H

http://source.winehq.org/git/wine.git/blob/360a3f914235e04216a3691390662885c...

- _SI_OBJECT_INFO

http://source.winehq.org/git/wine.git/blob/0453b03e86fb28f3f87f1a51c69946157...

- _Lockit

http://source.winehq.org/git/wine.git/blob/e3174d93d8c898ea6ecd9c8d8f9bb5b9f...

This usage does not fit to the expected naming conventions of the C language
standard.
https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not...

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #1 from Nikolay Sivov  2012-02-09 07:33:28 CST ---
I think there's nothing to be done here unless we get a real collision.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #2 from Markus Elfring  2012-02-09 07:40:20 CST ---
(In reply to comment #1)

Would you like to avoid any potential damage because of a wrong identifier
selection?

Are there any chances to stop repeating historical coding errors like they were
made by Microsoft?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #3 from Nikolay Sivov  2012-02-09 07:56:52 CST ---
(In reply to comment #2)
> Would you like to avoid any potential damage because of a wrong identifier
> selection?

Wrong identifier selection from what? From standard library?
> Are there any chances to stop repeating historical coding errors like they were
> made by Microsoft?

I don't know what are you talking about.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
           Platform|All                         |Other
         Resolution|                            |INVALID
         OS/Version|All                         |other

--- Comment #4 from Dmitry Timoshkov  2012-02-09 08:15:10 CST ---
There is nothing to fix.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #5 from Markus Elfring  2012-02-09 08:18:57 CST ---
(In reply to comment #3)

Can it be that some identifiers (e. g. with leading underscores) are still in
use today despite they correspond to undefined behaviour since the C
programming languages was finally standardised years ago?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #6 from Dmitry Timoshkov  2012-02-09 08:26:08 CST ---
As long as the code compiles there is nothing to fix/worry about.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #7 from Markus Elfring  2012-02-09 08:33:29 CST ---
(In reply to comment #6)

Would any software developers like to reduce the amount of source code that
builds on undefined behaviour?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #8 from Dmitry Timoshkov  2012-02-09 09:41:53 CST ---
(In reply to comment #7)
> (In reply to comment #6)
>
> Would any software developers like to reduce the amount of source code that
> builds on undefined behaviour?

What undefined behaviour are you talking about?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

Markus Elfring  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |

--- Comment #9 from Markus Elfring  2012-02-11 00:07:25 CST ---
(In reply to comment #8)
> What undefined behaviour are you talking about?

How do you think about the items in a corresponding list from the Software
Engineering Institute?

https://www.securecoding.cert.org/confluence/display/seccode/CC.+Undefined+B...

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #10 from Dmitry Timoshkov  2012-02-11 04:28:46 CST ---
(In reply to comment #9)
> How do you think about the items in a corresponding list from the Software
> Engineering Institute?
>
> https://www.securecoding.cert.org/confluence/display/seccode/CC.+Undefined+B...

I'm sorry, but this have nothing to do with "security", or "undefined
behaviour" of the *compiled code*. Besides, examples in your first comment
include definitions of public SDK interfaces which Wine must follow.

As long as the code compiles and works as intended there is nothing
to worry about. Let's leave pure theoretical speculations to somebody
else.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #11 from Markus Elfring  2012-02-12 01:24:32 CST ---
(In reply to comment #10)
> I'm sorry, but this have nothing to do with "security", or "undefined
> behaviour" of the *compiled code*.

I disagree to this opinion.

Some source code does not completely adhere to the current rules of the C
programming language. The source files are consequently not as secure as
without rule violations.
> Besides, examples in your first comment include definitions of public
> SDK interfaces which Wine must follow.

I assume that Microsoft and corresponding developers should adjust something to
improve software correctness.
> As long as the code compiles and works as intended there is nothing
> to worry about.

I am curious how long such a violated rule will be further tolerated.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #12 from Dmitry Timoshkov  2012-02-12 20:16:14 CST ---
(In reply to comment #11)
> > I'm sorry, but this have nothing to do with "security", or "undefined
> > behaviour" of the *compiled code*.
>
> I disagree to this opinion.
>
> Some source code does not completely adhere to the current rules of the C
> programming language. The source files are consequently not as secure as
> without rule violations.

Security of source files is something different to the security of
the compiled code. IMHO the "security of source files" term is a pure
speculation. A programmer is free to use any identifiers and preprocessor
definitions in his/her program as long as the *compiled code* works and
doesn't have side effects or security concerns.
> > Besides, examples in your first comment include definitions of public
> > SDK interfaces which Wine must follow.
>
> I assume that Microsoft and corresponding developers should adjust something to
> improve software correctness.

There is no point to do that, and backwards compatibility requires to keep
that as it is.
> > As long as the code compiles and works as intended there is nothing
> > to worry about.
>
> I am curious how long such a violated rule will be further tolerated.

As long as it works and does what it supposed to do I'd guess.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #13 from Markus Elfring  2012-02-13 01:40:38 CST ---
(In reply to comment #12)
> A programmer is free to use any identifiers and preprocessor definitions
> in his/her program as long as the *compiled code* works and doesn't have
> side effects or security concerns.

The mentioned software development freedom is restricted if you would like to
provide source code that is compliant to the (current) C standard. If the
source files do not completely adhere to the programming language rules, I find
that the trust in the functionality of the corresponding compilation result
will be reduced.
> There is no point to do that, and backwards compatibility requires
> to keep that as it is.

I imagine that there are still opportunities to fix rule violations
incrementally.
How do you think about to introduce additional preprocessor macros?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #14 from Dmitry Timoshkov  2012-02-13 03:46:05 CST ---
(In reply to comment #13)
> The mentioned software development freedom is restricted if you would like to
> provide source code that is compliant to the (current) C standard.

The C compiler is the final judge, I'd guess.
> If the
> source files do not completely adhere to the programming language rules, I find
> that the trust in the functionality of the corresponding compilation result
> will be reduced.

In which way?
> > There is no point to do that, and backwards compatibility requires
> > to keep that as it is.
>
> I imagine that there are still opportunities to fix rule violations
> incrementally.
> How do you think about to introduce additional preprocessor macros?

For what purpose?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #15 from Markus Elfring  2012-02-13 04:22:43 CST ---
(In reply to comment #14)
> The C compiler is the final judge, I'd guess.

No. - The tool implementation can also apply wrong or unexpected identifiers.
> In which way?

How much can you trust the compilation result which was generated by undefined
behaviour?
> For what purpose?

Preprocessor macros for update candidates:
1. Include guards
2. Definition of data structures

Would any more software developers prefer to reuse standard-compliant
identifiers?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #16 from Dmitry Timoshkov  2012-02-13 04:52:19 CST ---
(In reply to comment #15)
> (In reply to comment #14)
> > The C compiler is the final judge, I'd guess.
>
> No. - The tool implementation can also apply wrong or unexpected identifiers.
> > In which way?
>
> How much can you trust the compilation result which was generated by undefined
> behaviour?
> > For what purpose?
>
> Preprocessor macros for update candidates:
> - Include guards
> - Definition of data structures
>
> Would any more software developers prefer to reuse standard-compliant
> identifiers?

You can always send a (small) patch to wine-patches in order to receive
an authorized opinion.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #17 from Markus Elfring  2012-02-13 05:00:28 CST ---
(In reply to comment #16)
> You can always send a (small) patch to wine-patches in order to receive
> an authorized opinion.

I guess that corresponding patches will not be small. I try to check the change
acceptance before.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #18 from Alexandre Julliard  2012-02-13 05:03:32 CST ---
It won't be accepted. There's no reason to change anything. Using underscore
prefixes is OK in system headers, which is what Wine headers are.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #19 from Markus Elfring  2012-02-13 05:07:26 CST ---
(In reply to comment #18)
> Using underscore prefixes is OK in system headers, which is what Wine headers are.

Do any identifiers in these headers belong to the implementation of a C
compiler?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #20 from Alexandre Julliard  2012-02-13 05:39:26 CST ---
They are the Windows SDK, so yes, it's part of the compiler environment as far
as building Windows code is concerned.

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

--- Comment #21 from Markus Elfring  2012-02-13 05:49:06 CST ---
(In reply to comment #20)
> They are the Windows SDK, so yes, it's part of the compiler environment as far
> as building Windows code is concerned.

I find that the Windows application interface and corresponding software
development kit is a platform. But is it an inplementation of a C or C++
compiler by itself?

[Bug 29845] reserved identifier violation

http://bugs.winehq.org/show_bug.cgi?id=29845

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
                 CC|                            |[e-mail]

--- Comment #22 from Jerome Leclanche  2012-02-24 06:07:02 CST ---
Closing