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

Jump to bottom

bytes: API documentation of ErrTooLarge is incorrect #12287

Closed
adonovan opened this issue Aug 24, 2015 · 3 comments
Closed

bytes: API documentation of ErrTooLarge is incorrect #12287

adonovan opened this issue Aug 24, 2015 · 3 comments
Labels
FrozenDueToAge

Comments

@adonovan
Copy link
Member

Various comments in the API of bytes.Buffer say that failure to allocate a buffer causes ErrTooLarge to be returned. I think they're all false, since they assume that the error caused by the call to make in makeSlice is a panic that can be recovered from using recover, when in fact it is a fatal error, at least in the gc implementation (though this behavior isn't prescribed by the spec).

I don't think the API as specified can be implemented without runtime magic and/or a spec change. We should probably strike all mention of ErrTooLarge but leave the variable there with a deprecation comment.
@dominikh
Copy link
Member

There is one instance where a recoverable panic occurs, when the argument to make is unrealistically huge (exceeding the allowed arena size?)

@ianlancetaylor
Copy link
Contributor

On a 32-bit system you will get a recoverable panic if you call make([]byte, 0x80000000).

@rsc
Copy link
Contributor

rsc commented Oct 23, 2015

As Ian said, this seems to work as intended. It's just that on a 64-bit system there's no such thing as "too large".

@rsc rsc closed this as completed Oct 23, 2015
@golang golang locked and limited conversation to collaborators Oct 24, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dominikh @rsc @ianlancetaylor @adonovan @gopherbot