Codebase invokes lots of undefined behavior by using reserved identifiers #4909

Closed
opened 2026-01-30 23:59:58 +00:00 by claunia · 3 comments
Owner

Originally created by @Longhanks on GitHub (Nov 10, 2019).

The code base seems to use lots of identifiers for private member objects or functions that start with an underscore, followed by an uppercase letter, such as IslandWindow::_ApplyWindowSize (/src/cascadia/WindowsTerminal/IslandWindow.h#L99).

The C++ standard however says:

In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required. Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.

(From https://eel.is/c++draft/lex.name#3.1)

Using such identifiers is technically an invocation of undefined behavior.

Originally created by @Longhanks on GitHub (Nov 10, 2019). The code base seems to use lots of identifiers for private member objects or functions that start with an underscore, followed by an uppercase letter, such as `IslandWindow::_ApplyWindowSize` ([/src/cascadia/WindowsTerminal/IslandWindow.h#L99](https://github.com/microsoft/terminal/blob/db797580923472c08613f054364097be06d73229/src/cascadia/WindowsTerminal/IslandWindow.h#L99)). The C++ standard however says: > In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required. Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use. (From https://eel.is/c++draft/lex.name#3.1) Using such identifiers is technically an invocation of undefined behavior.
Author
Owner

@miniksa commented on GitHub (Nov 11, 2019):

Yeah.... someone on our team brought this up once but we determined it wasn't a big enough deal to spend time on at the moment. If you or anyone else is interested in fixing all the names to be compliant with the standard (and hopefully also write a test or something to enforce that we don't violate it again), we'd be happy to take it.

@miniksa commented on GitHub (Nov 11, 2019): Yeah.... someone on our team brought this up once but we determined it wasn't a big enough deal to spend time on at the moment. If you or anyone else is interested in fixing all the names to be compliant with the standard (and hopefully also write a test or something to enforce that we don't violate it again), we'd be happy to take it.
Author
Owner

@zadjii-msft commented on GitHub (Dec 19, 2019):

Oh my goodness this is actually already tracked in /dup #721

@zadjii-msft commented on GitHub (Dec 19, 2019): Oh my goodness this is actually already tracked in /dup #721
Author
Owner

@ghost commented on GitHub (Dec 19, 2019):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Dec 19, 2019): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#4909