Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix aliasing-based undefined behavior in string functions. #11215

Merged
merged 1 commit into from
May 26, 2020

Conversation

zekoz
Copy link
Contributor

@zekoz zekoz commented May 22, 2020

Copies these functions verbatim from musl v1.2.0. #10910 #7279

@zekoz zekoz force-pushed the aliasing-ub branch 5 times, most recently from 3e15038 to c0f4cb6 Compare May 22, 2020 14:04
@sbc100
Copy link
Collaborator

sbc100 commented May 22, 2020

Can you mention this in system/lib/libc/README.md?

Copies these functions verbatim from musl v1.2.0. Also adds weak_alias
macro to features.h to reflect upstream musl.
@zekoz
Copy link
Contributor Author

zekoz commented May 22, 2020

Can you mention this in system/lib/libc/README.md?

Added

@@ -33,4 +33,7 @@
#define _Noreturn
#endif

#define weak_alias(old, new) \
extern __typeof(old) new __attribute__((__weak__, __alias__(#old)))
Copy link
Collaborator

Choose a reason for hiding this comment

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

This looks like its already defined in src/internal/libc.h.. And in upstream musl it moved to the internal header src/include/features.h (as opposed to this features.h header which is externally visible).

Is this a necessary part of the change? Do the sources in string not already include src/internal/libc.h?

I wonder if its worth bringing over the new src/include/features.h wrapper header?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, you nerd-sniped me. I am seeing how much v1.2.0 I can pull in here.

Copy link
Collaborator

Choose a reason for hiding this comment

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

If possible I'd recommend keeping this change focused, unless you want to do a full musl upgrade .. which is quite a big endeavor. (I think it took weeks or maybe months to completely last time it was done).

Copy link
Member

@kripken kripken May 26, 2020

Choose a reason for hiding this comment

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

I agree, let's land this now, but @zekoz please submit more PRs with more 1.2 pieces or even the whole upgrade!

@kripken kripken merged commit c5e2dd1 into emscripten-core:master May 26, 2020
sbc100 added a commit that referenced this pull request Jun 4, 2021
This was added in #11215 to maintain comatability with upgraded version
of stpcpy.c/stpncpy.c/strchrnul.c.

However, this macro was never indended to exposed outside of musl
itself.  In musl v1.2.2 this macro lives in the *internal* version of
features.h but musl v1.1.15 does't have an internal features.h.  Instead
this macro lives in libc.h in v1.1.15.

See: #14352
Fixes: #14350
sbc100 added a commit that referenced this pull request Jun 4, 2021
This was added in #11215 to maintain comatability with upgraded version
of stpcpy.c/stpncpy.c/strchrnul.c.

However, this macro was never indended to exposed outside of musl
itself.  In musl v1.2.2 this macro lives in the *internal* version of
features.h but musl v1.1.15 does't have an internal features.h.  Instead
this macro lives in libc.h in v1.1.15.

See: #14352
Fixes: #14350
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants