programing

->>>오래된 연산자인가, 오타/오류인가?

prostudy 2022. 5. 8. 22:02
반응형

->>>오래된 연산자인가, 오타/오류인가?

내가 읽는 동안 나는 1993년에 작성된 WG14 결함 보고서 #51(또는 아마도 1893년, 그들은 세기와 밀레니엄을 벗어났다)을 우연히 발견했다.거기 코드 샘플에서 오퍼레이터가 스펠링으로->>에 대한 포인터에 사용되다struct. 찾은 연산자 우선 순위 표에서 찾을 수 없으므로, 연산자가 맞는지 궁금하고, 만약 그렇다면 이 연산자는 무엇을 하는가(또는 했는가)?

처음에는 오타라고 생각했지만, 질문에 대한 응답으로 본문에는 두 번, 코드 샘플에는 또 한 번 더 재현되고, 나 같은 초보자에게 뛰어나왔을 때, 눈치채지 못하고 적어도 두 명 이상의 C 전문가들을 그냥 지나쳐 버렸다는 것을 믿기가 힘들다.그것은 또한 코드의 초점에 있고, 매우 쉽게 알아차릴 수 있으며, 결코 고쳐지지 않았다.

여기에 들여쓰기가 추가된 코드가 있다.

#include <stdlib.h>

struct A {
    char x[1];
};

main()
{
    struct A *p = (struct A *) malloc(sizeof(struct A) + 100);
    p->>x[5] = '?';  /* This is the key line [for both them and us] */
    return 0;
}

나는 이 코드를 C와 C++ 컴파일러 둘 다로 컴파일러로 컴파일하려고 했는데 둘 다 구문 분석하는 데 실패했다.아마도 이것은 더 이상 사용되지 않는 C의 초기 버전에서 어떤 교환원이었을까?

이것은 이 운영자의 이름이 무엇인가: "-->"라는 질문처럼 수상하게 느껴지지만, 나는 이것이 다른 두 운영자의 결합이라고 생각하지 않는다, 어떻게 분할되어 유효할 수 있을지는 모르겠다.

전사 과정에서 문제처럼 보인다.DR 42에도 비슷한 문제가 있는데, 여기서 보다 큼 기호가 두 배로 늘어난다. http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_042.html

나는 1992년에 C를 배웠고, 그 당시에는 그런 조작자가 없었다고 100% 확신한다.

맥락에서 보면p->>x[5]좀 더 친숙한 화살 조작자와 정확히 같은 일을 하는 것으로 보인다고 추측할 수 있다.->따라서 오타가 될 가능성이 높다.


또는 코드를 HTML로 변환할 때 인코딩 문제가 될 수 있다. 그 페이지의 출처를 보면 이스케이프 코드와 리터럴이 이상하게 섞여 있는 것을 알 수 있다.<그리고>문자:

<TT><B>#include &lt;stdlib.h><BR>

이것은 전사적 오류일 것 같지만, 어쨌든, 단지 그것이 교묘한 속임수가 아니라는 것을 분명히 하기 위해서, 진짜 C 컴파일러가 이 구문을 어떻게 해석할 것인지 적어두는 것이 유용할 것이라고 생각한다.가장 먼저 알아야 할 것은 C11 §6.5.4p4(기술적으로 N1570, 이 언어는 C89 이후 변경되지 않음, 섹션 번호가 아마도 달랐지만, 강조 나의 언어)이다.

입력 스트림을 지정된 문자까지 사전 처리 토큰으로 구문 분석했다면 다음 사전 처리 토큰은 사전 처리 토큰을 구성할 수 있는 가장 긴 문자 시퀀스다.

즉, 6자로 된 끈을 의미한다." p->>x"로 토큰화되어야 한다.p -> > x, 아니다.p - >> x또는p - > > x. (이 경우 실제로 중요하지 않으며, 어느 쪽이든 구문 오류일 수 있지만, 이 규칙은 의도한 대로 구문 분석하는 프로그램 사이의 차이일 수 있고, 표준은 예를 들어준다.x+++++y 로 된다.x++ ++ +y, 으로가 아니다.x++ + ++y 비록 잘

다음으로 알아야 할 것은 그야말로 우파의 주장이라는 것이다.->연산자는 제6.5.2조의 수정 후 표현에 대한 문법 규칙에 따른 식별자여야 한다. 분명히>식별자가 아니어서 구문 오류가 확실해

참조URL: https://stackoverflow.com/questions/13050234/is-this-an-old-operator-or-a-typo-error

반응형