자바 고차스 - 비트 와이즈 대 부울 연산자

> "자바 고차"- 실수로 구현하기 쉬운 일반적인 실수 패턴.

부울 비교 연산자 대신 Bitwise 연산자 사용: 실수로 빠지게 되는 매우 간단한 Java Gotcha.

예를 들어 간단한 오용은 "&"를 실제로 쓰려는 의미일 때 "&"를 작성하게 될 수 있습니다.

코드를 검토할 때 학습하는 일반적인 추론은 다음과 입니다.

조건부 문에 사용될 때 "&" 또는 "|"> 의도되지 않았을 것입니다.

이 블로그 게시물에서는 추론을 탐구하고 이 코딩 문제를 식별하고 해결할 수 있는 방법을 식별합니다.

문제가 뭔가요? Bitwise 작업은 부울과 잘 작동합니다.

Booleans와 Bitwise 연산자 사용이 완벽하게 유효하므로 Java는 구문 오류를 보고하지 않습니다.

Bitwise OR (|)과 Bitwise AND (&)에 대한 진실 테이블을 탐색하기 위해 JUnit 테스트를 구성하면 Bitwise 운영자의 출력이 진실 표와 일치하는 것을 볼 수 있습니다. 이를 감안할 때 Bitwise 운영자의 사용은 문제가 아니라고 생각할 수 있습니다.

그리고 진실 테이블

@Test
    void bitwiseOperatorsAndTruthTable(){
          Assertions.assertEquals(true, true & true);
          Assertions.assertEquals(false, true & false);
          Assertions.assertEquals(false, false & true);
          Assertions.assertEquals(false, false & false);
    }

테스트가 통과, 이것은 완벽하게 유효한 자바입니다.

또는 진실 표

   @Test
    void bitwiseOperatorsOrTruthTable(){
        Assertions.assertEquals(true, true | true);
        Assertions.assertEquals(true, true | false);
        Assertions.assertEquals(true, false | true);
        Assertions.assertEquals(false, false | false);
    }

이 테스트는 또한 통과, 왜 우리는 선호합니까 "&'와 "||"?

진실 테이블 이미지는 web.standfor.edu 진실 테이블 도구를 사용하여 만들어졌습니다.

문제: 단락 작동

진짜 문제는 Bitwise (&, |)와 부울 (&, ||) 운영자 사이의 행동의 차이입니다.

부울 연산자는 단락 연산자이며 필요한 만큼만 평가합니다.

예를 들어.

if (args != null & args.length() > 23) {
    System.out.println(args);
}

위의 코드에서 Bitwise 연산자가 사용되었기 때문에 두 부울 조건이 모두 평가됩니다.

• 아르그 != null
• args.length () > 23

이것은 args가 항상 args.length에 대한 검사를 수행하기 때문에 nullPointerException에 내 코드를 열어 둡니다.

부울 연산자 단락 평가

예를 들어 & 사용시

if (args != null && args.length() > 23) {
    System.out.println(args);
}

args!= null이 조건 표현식 평가가 중지되는 것을 잘못 평가한다는 것을 알자마자.

우리는 오른쪽을 평가할 필요가 없습니다.

오른쪽 조건의 결과가 어떻든 간에 부울 표현의 최종 값은 거짓입니다.

그러나 프로덕션 코드에서는 이런 일이 일어나지 않을 것입니다.

이것은 매우 쉬운 실수이며 항상 정적 분석 도구에 의해 포착되지는 않습니다.

나는이 패턴의 공개 예를 찾을 수 있는지 확인하기 위해 다음과 같은 Google Dork를 사용했습니다.

파일 유형:자바 경우 "!=null & "
이 검색은 루트윈도우 컨테이너에서 안드로이드에서 일부 코드를 다시 가져
isDocument = 의도!= null 및 의도.isDocument()

할당 문에서 Bitwise 연산자(Bitwise operators)를 사용하여 값을 마스크하기 때문에 코드 검토를 전달할 수 있는 코드 유형입니다. 그러나 이 경우 결과는 위의 if 문 예제와 동일합니다. 의도가 null이면 NullPointer예외가 throw됩니다.

종종 방어적으로 코딩하고 중복 코드를 작성하기 때문에 이 구문에서 벗어나는 경우가 많습니다. 대부분의 사용 사례에서 != null에 대한 검사가 중복될 수 있습니다.

이는 프로덕션 코드의 프로그래머가 오류한 오류입니다.

검색에 대한 결과가 얼마나 현재인지 는 모르겠지만 검색을 실행했을 때 Google, Amazon, Apache ... 그리고 나.

오픈 소스 프로젝트 중 하나에 대한 최근 풀 요청은 이 오류를 정확하게 해결하는 것이었습니다.

if(type!=null & type.trim().length()>0){
    acceptMediaTypeDefinitionsList.add(type.trim());
}

이 것을 찾는 방법

몇 가지 정적 분석기에서 샘플 코드를 확인했을 때, 그 중 어느 것도 이 숨겨진 자폭 코드를 선택하지 않았습니다.

팀으로서 Secure Code Warrior , 우리는 만들고 매우 간단한 검토 Sensei 이 것을 선택할 수있는 조리법.

Bitwise 연산자는 완벽하게 유효하고 종종 할당에 사용되기 때문에 우리는 문제가있는 코드를 찾기 위해 문의 의 사용 사례및 Bitwise & 사용에 초점을 맞춥니다.

search:
  expression:
    anyOf:
    - in:
        condition: {}
    value:
      caseSensitive: false
      matches: ".* & .*"

이렇게 하면 조건 표현식으로 사용될 때 "&" 일치하는 정규 식을 사용합니다. 예를 들어 if 문에서.

이를 해결하기 위해 우리는 다시 정규 식에 의존했습니다. 이번에는 QuickFix의 sed 함수를 사용하여 표현식의 및 표현식을 &로 전 세계적으로 대체합니다.

availableFixes:
  - name: "Replace bitwise AND operator to logical AND operator"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

끝 노트

이는 Bitwise 연산자의 가장 일반적인 오용(예: 부울 연산자가 실제로 의도한 경우)을 다룹니다.

과제 예제와 같은 다른 상황이 있지만 레시피를 작성할 때 는 잘못된 긍정 식별을 피해야 하므로 그렇지 않으면 조리법이 무시되거나 꺼집니다. 우리는 가장 일반적인 발생에 맞게 조리법을 구축 할 수 있습니다. 만큼 Sensei 더 많은 일치 조건을 커버하기 위해 검색 기능에 추가 특이성을 추가할 수 있습니다.

현재의 형태로, 이 조리법은 라이브 사용 사례의 많은 식별 것, 그리고 가장 중요한 것은,내 프로젝트에보고 된 하나.

참고 : 찰리 에릭센, 마티유 칼리, 로빈 클레어하우트, 브라이센 Ackx, 네이선 데스멧, 다우니 로버슈텐 - 공정한 몇 코드 전사는이 예와 조리법 검토에 기여했다. 당신의 도움을 주셔서 감사합니다.

---

설치할 수 있습니다. Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드"

우리는 '에서 이러한 블로그 게시물 (이 포함)에 대한 소스 코드와 조리법을 많이 가지고 sensei -블로그 예제의 리포지토리는 Secure Code Warrior GitHub 계정.

https://github.com/securecodewarrior/sensei-blog-examples

자세히 알아보기 Sensei