Skip to content

Restore line in newlocale.c that was lost in #4813#13584

Merged
sbc100 merged 1 commit into
masterfrom
fix_newlocale
Mar 3, 2021
Merged

Restore line in newlocale.c that was lost in #4813#13584
sbc100 merged 1 commit into
masterfrom
fix_newlocale

Conversation

@sbc100

@sbc100 sbc100 commented Mar 3, 2021

Copy link
Copy Markdown
Collaborator

When musl was last upgraded this malloc line removed from newlocale.c,
perhaps by accident.

This restores the behaviour of musl which is to allow newlocale with
arbitrary names to succeed. I verified that this is the case using musl
on my desktop.

The reason that test_locale_wrong was passing prior to #4813 is that
the musl older version of musl we were using prior to #4813 rejected
all locales except for "C" and "POSIX".

Upstream version that we are currently based on:
https://github.com/emscripten-core/musl/blob/v1.1.15/src/locale/newlocale.c#L44

Upstream version of musl that we were previously using:
https://github.com/emscripten-core/musl/blob/0b44a0315b47dd8eced9f3b7f31580cf14bbfc01/src/locale/newlocale.c#L5

When musl was last upgraded this malloc line removed from newlocale.c,
perhaps by accident.

This restores the behaviour of musl which is to allow `newlocale` with
arbitrary names to succeed.  I verified that this is the case using musl
on my desktop.

The reason that test_locale_wrong was passing prior to #4813 is that
the musl older version of musl we were using prior to #4813 rejected
all locales except for "C" and "POSIX".

Upstream version that we are currently based on:
https://github.com/emscripten-core/musl/blob/v1.1.15/src/locale/newlocale.c#L44

Upstream version of musl that we were previously using:
https://github.com/emscripten-core/musl/blob/0b44a0315b47dd8eced9f3b7f31580cf14bbfc01/src/locale/newlocale.c#L5
@sbc100 sbc100 mentioned this pull request Mar 3, 2021
@sbc100 sbc100 requested a review from kripken March 3, 2021 03:03
@sbc100 sbc100 enabled auto-merge (squash) March 3, 2021 05:49

@kripken kripken left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

lgtm % comment

Comment thread tests/test_core.py

def test_setlocale(self):
self.do_run_in_out_file_test('tests', 'core', 'test_setlocale.c')

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

these feel excessive to me in core as I don't think opt levels matter for them? how about other?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Sure, but I think there are a whole lot of tests that fall into that category no? For example this existing test_locale was in the wrong place according your assessment? How should we make this decision about which test suite a give test belongs in? (I'm sure I filed a bug about this discussion at some point but I can't seem to find it now).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

My reasoning is that core runs on various opt levels, so tests that want that should be there. Otherwise, it can be in other.

A codegen test for exceptions would be in core, for example, to see the optimizer can handle it. A libc issue like this could be in other.

@sbc100 sbc100 merged commit 78fa15d into master Mar 3, 2021
@sbc100 sbc100 deleted the fix_newlocale branch March 3, 2021 19:45
@kripken

kripken commented Mar 3, 2021

Copy link
Copy Markdown
Member

Ah I didn't notice the auto-merge. Anyhow, no worries, if you agree on the comment it can be a followup (or not if not).

@sbc100

sbc100 commented Mar 3, 2021

Copy link
Copy Markdown
Collaborator Author

But core also has other configurations too (asan, SAFE_HEAP, STACK_OVERFLOW_CHECK, MINIMAL_RUNTIME etc..). Sometimes when I add a new feature of setting I add a new core test config in the hope I can run a "big enough" set of general tests to find most bugs.

Also, core is currently has a lot of general stdlib tests. For example test_stdlibs, test_strtoll_hex, test_time_c. It looks like there are tons of them. Should we move all them to other?

@sbc100

sbc100 commented Mar 3, 2021

Copy link
Copy Markdown
Collaborator Author

I'm not disagreeing with you, but rather trying to decide on a policy.

@kripken

kripken commented Mar 3, 2021

Copy link
Copy Markdown
Member

I think there won't ever be a simple rule. Some libc tests should run in various modes to see the optimizer doesn't do bad things to strtoll, say, which might have interesting irreducible control flow. And asan can find libc bugs, good point.

But when we don't have a reasonable reason to think of wanting to run multiple modes, I'd say other. Otherwise our test times will rise unnecessarily.

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.

2 participants