Skip to content

use bit shift to set bitflags #8428

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

Merged
merged 1 commit into from
Apr 23, 2022
Merged

use bit shift to set bitflags #8428

merged 1 commit into from
Apr 23, 2022

Conversation

divinity76
Copy link
Contributor

nitpicking, this makes it practically impossible to accidentally use a number with 2 bits set in the future,
it's also my personal preference, its trivial to see "PHP_FILE_NO_DEFAULT_CONTEXT use bit 4" and that "the next unused bit is bit 5"

nitpicking, this makes it practically impossible to accidentally use a number with 2 bits set in the future, 
it's also my personal preference, its trivial to see "PHP_FILE_NO_DEFAULT_CONTEXT use bit 4" and that "the next unused bit is bit 5"
@divinity76
Copy link
Contributor Author

divinity76 commented Apr 23, 2022

speaking of accidentally using a number with 2 bits set, why is LOCK_UN using a number with 2 bits set in https://github.com/php/php-src/blob/master/ext/standard/flock_compat.h#L48 ? (3 / 00000011 )

a number that collide with both LOCK_SH and LOCK_EX? well now i'm confused a strange choice, now implementors must make sure to check for LOCK_UN before LOCK_SH/LOCK_EX, if an implementor accidentally check for LOCK_SH/LOCK_EX before LOCK_UN, the collision would break it ^^ and it's a choice NOT shared with C, i might add. C use 1, 2, and 8 (all of which doesn't collide and use only 1 bit), PHP use 1,2, and 3 (where 3 use 2 bits and collide with 1 and 2)

@Girgias Girgias merged commit 820f695 into php:master Apr 23, 2022
@Girgias
Copy link
Member

Girgias commented Apr 23, 2022

speaking of accidentally using a number with 2 bits set, why is LOCK_UN using a number with 2 bits set in https://github.com/php/php-src/blob/master/ext/standard/flock_compat.h#L48 ? (3 / 00000011 )

a number that collide with both LOCK_SH and LOCK_EX? well now i'm confused a strange choice, now implementors must make sure to check for LOCK_UN before LOCK_SH/LOCK_EX, if an implementor accidentally check for LOCK_SH/LOCK_EX before LOCK_UN, the collision would break it ^^ and it's a choice NOT shared with C, i might add. C use 1, 2, and 8 (all of which doesn't collide and use only 1 bit), PHP use 1,2, and 3 (where 3 use 2 bits and collide with 1 and 2)

That looks like a bug to me then.

@divinity76
Copy link
Contributor Author

@Girgias yeah it loosk super weird, and it breaks code like

<?php
function f(int $flags){
    if($flags & LOCK_SH){
        echo "im handling a LOCK_SH request!";
    }elseif($flags & LOCK_EX){
        echo "im handling a LOCK_EX request!";
    }elseif($flags === LOCK_UN){
        echo "im handling a LOCK_UN request!";
    }else{
        echo "didn't understand those flags...";
    }
}
f(LOCK_UN);

which is fine in C (and i guess, most languages), but in PHP produce => im handling a LOCK_SH request!

divinity76 added a commit to divinity76/php-src that referenced this pull request Apr 23, 2022
nitpicking, this makes it practically impossible to accidentally use a number with 2 bits set in the future,
it's also my personal preference, its trivial to see "LOCK_NB use bit 2" and that "the next unused bit is bit 4"

here it also highlights that there is something strange about the userland LOCK_UN constant
which has been (or is being?) discussed here php#8428
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