[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: wine-bugs(a)winehq.org ReportedBy: Markus.Elfring(a)web.de 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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> 2012-02-09 07:33:28 CST --- I think there's nothing to be done here unless we get a real collision. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #2 from Markus Elfring <Markus.Elfring(a)web.de> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #3 from Nikolay Sivov <bunglehead(a)gmail.com> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Platform|All |Other Resolution| |INVALID OS/Version|All |other --- Comment #4 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2012-02-09 08:15:10 CST --- There is nothing to fix. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #5 from Markus Elfring <Markus.Elfring(a)web.de> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #6 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2012-02-09 08:26:08 CST --- As long as the code compiles there is nothing to fix/worry about. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #7 from Markus Elfring <Markus.Elfring(a)web.de> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #8 from Dmitry Timoshkov <dmitry(a)baikal.ru> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 Markus Elfring <Markus.Elfring(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|INVALID | --- Comment #9 from Markus Elfring <Markus.Elfring(a)web.de> 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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #10 from Dmitry Timoshkov <dmitry(a)baikal.ru> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #11 from Markus Elfring <Markus.Elfring(a)web.de> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #12 from Dmitry Timoshkov <dmitry(a)baikal.ru> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #13 from Markus Elfring <Markus.Elfring(a)web.de> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #14 from Dmitry Timoshkov <dmitry(a)baikal.ru> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #15 from Markus Elfring <Markus.Elfring(a)web.de> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #16 from Dmitry Timoshkov <dmitry(a)baikal.ru> 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: 1. Include guards 2. 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #17 from Markus Elfring <Markus.Elfring(a)web.de> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #18 from Alexandre Julliard <julliard(a)winehq.org> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #19 from Markus Elfring <Markus.Elfring(a)web.de> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #20 from Alexandre Julliard <julliard(a)winehq.org> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 --- Comment #21 from Markus Elfring <Markus.Elfring(a)web.de> 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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29845 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |adys.wh(a)gmail.com --- Comment #22 from Jerome Leclanche <adys.wh(a)gmail.com> 2012-02-24 06:07:02 CST --- Closing -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org