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

Check bounds upon construction of SubArrays. #10296

Merged
merged 2 commits into from Feb 24, 2015
Merged

Conversation

timholy
Copy link
Sponsor Member

@timholy timholy commented Feb 23, 2015

Fixes #9924, and see #4044. It seems appropriate to say "hoisted by my own petard," but of course it's not like we used to check and now we don't.

This is not quite as powerful a solution as the one outlined in #4044 (comment), but that can't happen until something like #8227 is merged.

@jakebolewski
Copy link
Member

I like the suffix 'unsafe'.

@timholy
Copy link
Sponsor Member Author

timholy commented Feb 23, 2015

Will change, it's more consistent that way.

In places where one wants to live dangerously, one can call
Base.sub_unsafe/Base.slice_unsafe. So in a sense this gives the
benefits of #4044.
@timholy
Copy link
Sponsor Member Author

timholy commented Feb 23, 2015

Our OSX tests are starting to get a little close to that 50 minute timeout limit: https://travis-ci.org/JuliaLang/julia/builds/51845135

@timholy
Copy link
Sponsor Member Author

timholy commented Feb 23, 2015

It just takes sooo long for the tests to run, I thought it better to save the CPU cycles for other people.

I agree it's a little strange, but I decided it would be OK here. There's no "code," so it can't break anything other than tests themselves (we'll know soon enough if it causes problems for other PRs), and I did try it on my laptop first.

timholy added a commit that referenced this pull request Feb 24, 2015
Check bounds upon construction of SubArrays.
@timholy timholy merged commit 144e847 into master Feb 24, 2015
@timholy timholy deleted the teh/sub_bc_constr branch February 24, 2015 03:20
@tkelman
Copy link
Contributor

tkelman commented Feb 25, 2015

True, CI will run on the merge commit anyway (unless you also go and put in [ci skip] there), so as long as people keep an eye on master it wouldn't cause problems for too long. I think OSX Travis is the slowest in overall runtime, but it also does a few more things than what runs on appveyor (debug build, make install, pkg test, etc). AIUI the OSX Travis VM's run on some relatively old hardware, so it's tough to optimize that much.

@timholy timholy mentioned this pull request Jun 20, 2015
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.

Segfault due to free(): invalid pointer
3 participants