Skip to content

gpu/utils: fix null pointer arithmetic in mp_log_source()#17715

Open
PatriciaBucataru wants to merge 1 commit intompv-player:masterfrom
PatriciaBucataru:fix/null-ptr-arithmetic-mp-log-source
Open

gpu/utils: fix null pointer arithmetic in mp_log_source()#17715
PatriciaBucataru wants to merge 1 commit intompv-player:masterfrom
PatriciaBucataru:fix/null-ptr-arithmetic-mp-log-source

Conversation

@PatriciaBucataru
Copy link
Copy Markdown

strchr() can return NULL when no newline is found. next was computed as end + 1 before the null check on the line below, which is undefined behaviour per C11 6.5.6.

Moved the next assignment after the null check.

@kasper93
Copy link
Copy Markdown
Member

kasper93 commented Apr 8, 2026

next was computed as end + 1 before the null check on the line below, which is undefined behaviour per C11 6.5.6.

This sounds as if we had invalid null check, when in fact the NULL + 1 value would never be used, because NULL check is on end. The change is correct, but we should make clear it's is to suppress UBSAN warnings and not a functional change.

@PatriciaBucataru
Copy link
Copy Markdown
Author

next was computed as end + 1 before the null check on the line below, which is undefined behaviour per C11 6.5.6.

This sounds as if we had invalid null check, when in fact the NULL + 1 value would never be used, because NULL check is on end. The change is correct, but we should make clear it's is to suppress UBSAN warnings and not a functional change.

Understood, do you want me to update the commit message?

Comment thread video/out/gpu/utils.c Outdated
Comment on lines +343 to +346
if (!end)
next = end = src + strlen(src);
else
next = end + 1;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

please add braces around the if-else

see: https://github.com/mpv-player/mpv/blob/master/DOCS/contribute.md

@PatriciaBucataru PatriciaBucataru force-pushed the fix/null-ptr-arithmetic-mp-log-source branch from c7705f6 to a22f2b3 Compare April 8, 2026 22:37
@N-R-K
Copy link
Copy Markdown
Contributor

N-R-K commented Apr 8, 2026

make clear it's is to suppress UBSAN warnings and not a functional change.

Incorrect.

Both gcc and clang have null pointer "optimization" which can optimize out the if (end) check by assuming it is false due to the end + 1 earlier.

@kasper93
Copy link
Copy Markdown
Member

kasper93 commented Apr 9, 2026

make clear it's is to suppress UBSAN warnings and not a functional change.

Incorrect.

Both gcc and clang have null pointer "optimization" which can optimize out the if (end) check by assuming it is false due to the end + 1 earlier.

Citation needed. I don't believe you such aggressive optimization is implemented in GCC, I would guess LLVM at some point could do it, but it also was tamed over the years.

And remember we are talking about the snippet of code in this PR, not some other theoretical case.

@N-R-K
Copy link
Copy Markdown
Contributor

N-R-K commented Apr 9, 2026

I don't believe you such aggressive optimization is implemented in GCC, I would guess LLVM at some point could do it, but it also was tamed over the years.

Hmm, looks like their null-pointer optimization currently only activates on dereferences. Not on invalid pointer arithmetic. Yet at least, such optimization would be permitted by the standard if they want to do it.


Anyhow, the current commit message is completely wrong @PatriciaBucataru. It's not "adding braces", that's just stylistic, it's fixing a UB.

@kasper93
Copy link
Copy Markdown
Member

kasper93 commented Apr 9, 2026

I don't believe you such aggressive optimization is implemented in GCC, I would guess LLVM at some point could do it, but it also was tamed over the years.

Hmm, looks like their null-pointer optimization currently only activates on dereferences. Not on invalid pointer arithmetic. Yet at least, such optimization would be permitted by the standard if they want to do it.

Sure, but will never happen. This would be breaking change and you cannot break majority of codebases. Also the point for UB optimization is to avoid "doing" something which is implicitly assumed by standard. For example in this case, it is already optimized into conditional move, with or without this PR, so anything else would be deoptimization.

strchr() can return NULL when no newline is found. Computing end + 1
before the null check on end is undefined behaviour per C11 6.5.6.
Move the next assignment inside the else branch to avoid the UB.
@PatriciaBucataru PatriciaBucataru force-pushed the fix/null-ptr-arithmetic-mp-log-source branch from a22f2b3 to 630a0e7 Compare April 9, 2026 06:43
@na-na-hi
Copy link
Copy Markdown
Contributor

Sure, but will never happen.

Similar thing has happened countless times to the Linux kernel to the point that Linux is basically using its own dialect of C requiring lots of specific GCC compiler flags.

@kasper93
Copy link
Copy Markdown
Member

Sure, but will never happen.

Similar thing has happened countless times to the Linux kernel to the point that Linux is basically using its own dialect of C requiring lots of specific GCC compiler flags.

Similar, not the same. Compiler will never do more work in the name of UB, it is always the other way around.

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.

5 participants