Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Fix multicharacter constant issues #27323

Merged
merged 5 commits into from
Oct 21, 2019

Conversation

franksinankaya
Copy link

@filipnavara
Copy link
Member

What is the rationale? It is valid C99 (section 6.4.4.4) and I was convinced it's also valid C++ (https://en.cppreference.com/w/cpp/language/character_literal) although I have not checked the specification.

@franksinankaya
Copy link
Author

There is some more information here:
https://stackoverflow.com/questions/7755202/multi-character-constant-warnings

"The value of an integer character constant containing more than one character (e.g., 'ab'), [...] is implementation-defined."

@franksinankaya
Copy link
Author

Warning is seen with gcc.

@filipnavara
Copy link
Member

filipnavara commented Oct 20, 2019

It is implementation-defined but still very much valid syntax. I have yet to see an implementation that doesn't translate it as 4-byte integer where each byte represents one character. At least in C99 mode gcc didn't warn me about it unless I explicitly turned on the warnings or used -pedantic.

@franksinankaya
Copy link
Author

It is probably 4 bytes in general but there is an issue with endianness.

From Wikipedia:

Multi-character constants (e.g. 'xy') are valid, although rarely useful — they let one store several characters in an integer (e.g. 4 ASCII characters can fit in a 32-bit integer, 8 in a 64-bit one). Since the order in which the characters are packed into one int is not specified, portable use of multi-character constants is difficult.

@filipnavara
Copy link
Member

...but there is an issue with endianness.

Generally this is valid concern. Then again, CoreCLR works only on little-endian machines and both GCC and Clang interpret it the same way.

@franksinankaya
Copy link
Author

I got your point. We are seeing a compilation error with GCC at this moment.

We have already fixed similar warnings in the past.
The workaround to not produce a warning is much more uglier than this change itself and unmanageable.

This change itself is also removing a compatibility issue. It is a win-win in the end.

Not taking it right now means we need to create a tech-debt for someone to cleanup in the future.

@franksinankaya
Copy link
Author

Also, I need to emphasize that this is the only place in entire code base where this warning is seen.

@mikedn
Copy link

mikedn commented Oct 20, 2019

This should probably just use memcmp or something like that, the current approach is likely unnecessary "optimization".

E.g.

if (memcmp(buffer + 4, "GenuineIntel", 12) == 0) {
...

All used C++ compilers transform this memcmp into a couple of integer compares.

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM modulo two nits.

franksinankaya and others added 2 commits October 20, 2019 19:18
Co-Authored-By: Jan Kotas <[email protected]>
Co-Authored-By: Jan Kotas <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants