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

utils: fix partial writes with write_file_at_with_flags #1656

Merged
merged 3 commits into from
Feb 3, 2025

Conversation

giuseppe
Copy link
Member

@giuseppe giuseppe commented Feb 3, 2025

@eriksjolund
Copy link
Contributor

Just sharing an idea:

Maybe another way is to return

crun_make_error (err, EINVAL, "too large ...", name);

in case (len > INT_MAX) and then just return 0 for success.

The advantage would be that a caller could just check for 0 if the caller
does not care about the type of error.

Otherwise your version is fine too. I'm not sure what's best.

@giuseppe
Copy link
Member Author

giuseppe commented Feb 3, 2025

Just sharing an idea:

Maybe another way is to return

crun_make_error (err, EINVAL, "too large ...", name);

in case (len > INT_MAX) and then just return 0 for success.

The advantage would be that a caller could just check for 0 if the caller does not care about the type of error.

Otherwise your version is fine too. I'm not sure what's best.

realistically this is never going to happen, we only write very small files. But I'd prefer to not raise an error just because we picked the wrong type that cannot store a size_t. Alternatively, we could just not return this information and limit it to -1 for errors, 0 for success. And on success the whole buffer was written

@eriksjolund
Copy link
Contributor

Alternatively, we could just not return this information and limit it to -1 for errors, 0 for success. And on success the whole buffer was written

Good idea. I like that as it makes it easier to read and understand the code.

@eriksjolund
Copy link
Contributor

Alternatively, we could just not return this information and limit it to -1 for errors, 0 for success. And on success the whole buffer was written

Good idea. I like that as it makes it easier to read and understand the code.

I just want to add that it does not matter so much. Choose whatever is most convenient for you.

@giuseppe
Copy link
Member Author

giuseppe commented Feb 3, 2025

I'd prefer to not change the semantic too much in this PR, as we would need to check that every caller doesn't really use this information

@giuseppe giuseppe merged commit 73d52bd into containers:main Feb 3, 2025
44 checks passed
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