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

Propagating 'const' to struct fields #2383

Closed
daurnimator opened this issue Apr 30, 2019 · 4 comments
Closed

Propagating 'const' to struct fields #2383

daurnimator opened this issue Apr 30, 2019 · 4 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@daurnimator
Copy link
Contributor

As noted in #2326: we have both

iovec = extern struct {
    iov_base: [*]u8,
    iov_len: usize,
};

and

iovec_const = extern struct {
    iov_base: [*]const u8,
    iov_len: usize,
};

Where the only difference is the const property on the iov_base field. This is done so that e.g. functions that don't modify their arguments (like writev) can take a [*]iovec_const, but functions that modify their arguments (like readv) take an [*]iovec.

However this gets extended: sendmsg/recvmsg take a msghdr which not only has a msg_iov member different that points to the relevant iovec, but the field msg_name gains a const across non-const/const variants.

pub const msghdr = extern struct {
    msg_name: ?*sockaddr,
    msg_namelen: socklen_t,
    msg_iov: [*]iovec,
    msg_iovlen: i32,
    __pad1: i32,
    msg_control: ?*c_void,
    msg_controllen: socklen_t,
    __pad2: socklen_t,
    msg_flags: i32,
};

pub const msghdr_const = extern struct {
    msg_name: ?*const sockaddr,
    msg_namelen: socklen_t,
    msg_iov: [*]iovec_const,
    msg_iovlen: i32,
    __pad1: i32,
    msg_control: ?*c_void,
    msg_controllen: socklen_t,
    __pad2: socklen_t,
    msg_flags: i32,
};
@andrewrk andrewrk added this to the 0.6.0 milestone May 1, 2019
@daurnimator
Copy link
Contributor Author

From IRC today: why isn't const sometype a valid type?
That would remove the requirement for both the e.g. mem.toSlice and mem.toSliceConst variants.

Idea:

const T is a type that has the same layout as T, but all child indirections are const-ified.
e.g. using the example in the original post, iovec_const = const iovec; and msghdr_const = const msghdr would be equivalent to the definitions given.

@andrewrk andrewrk added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Jan 5, 2020
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Jan 5, 2020
@andrewrk
Copy link
Member

I agree with the problem statement, but don't find the solution satisfactory.

@andrewrk andrewrk modified the milestones: 0.7.0, 0.6.0 Mar 29, 2020
@daurnimator
Copy link
Contributor Author

Shouldn't we keep the issue open as a known problem that needs fixing?

@BarabasGitHub
Copy link
Contributor

BarabasGitHub commented Oct 31, 2020

The idea proposed earlier seems like a bad idea. It's propagating const to types pointers point to. I think that's wrong, because just because you don't want the pointer to be modifiable doesn't mean you also don't want the pointed to data to be modifiable. And same the other way around. You can have a modifiable pointer that points to constant data.

However, this does seem related to an issue I ran into. #6897

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

3 participants