det translator: mid-record SYNC slack refused in layout check mode (sibling of #5694)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Start with det/engine_layout.py, det/layout.py, and the referenced #6117 test; compare how each lays out a SYNC item after an odd-length field run. First establish from IBM Enterprise COBOL documentation whether the slack belongs to the containing group before changing layout behavior. Done means census blockers no longer show LayoutDisagrees, the stated translation acceptance is met, burned estates remain unchanged, and the #6117 test reflects the new contract.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Sibling of #5694 (gap named in #6117's "Sibling gaps"), part of #5649.
What
In check mode (det/engine_layout.py, the default) the translator lays a record out twice: from the engine's layout (which models SYNCHRONIZED slack, #4266) and from its own det/layout.py (which models none). A SYNC binary item inside a record, after an odd-length run of fields, gets one byte of slack from the engine and none from the translator, so the program is refused whole with LayoutDisagrees.
#6117 pinned this as intended behaviour and left translator-side SYNC modelling as a frontier gap because no burned program has a mid-record SYNC item (all burned SYNC items are level-01, with no slack). This issue records the first program that hits it.
Evidence (counts only)
Census survey, 2026-10-28, main 4e739d9, translation only (cics_census.py survey over the 9 census clones, no burned or local corpora):
- 1 of 40 census programs is refused whole by this, and it is the only gap class that program has (
only gap1, non-burned 1). - The difference is pure slack: every elementary item before the SYNC item agrees in offset and size; from the SYNC item's group on, the engine is 1 byte further on (
engine @74, translator @73), and the record is 1 byte longer. - It is the only
LayoutDisagreesin the census; the burned estates have none.
Synthetic shape (made-up names):
01 REC.
05 A PIC X(73).
05 GRP.
10 N PIC S9(4) COMP-5 SYNC.
10 B PIC X(10).
Engine: GRP / N at 74 (halfword boundary). Translator: 73. Check mode refuses REC.
Two ways to close it
- Model SYNC slack in
det/layout.py(halfword / fullword / doubleword per USAGE, POINTER at the storage's width, C9), so check mode agrees. Before modelling, confirm from IBM's Enterprise COBOL documentation whether intra-record slack bytes belong to the group holding the SYNC item or sit before it. The engine currently starts the group after the slack, so its length excludes them. If IBM says otherwise, that is an engine fix and lands first (spec before code, no guessed semantics). - Finish #5649 step 3 / 4: retire the translator's own computation after its one-release check window. Engine mode already takes the engine's slack offsets (#6117 test), so the program would translate without a translator change.
Option 2 is the planned end state. Option 1 is only worth doing if check mode stays longer.
Acceptance
cics_census.py blockerson the census survey: noLayoutDisagreesrow; translated whole 8 -> >= 9 of 40 (non-burned), or the program's remaining holes named.- Burned estates unchanged (det-sweep ratchet green); #6117's test updated to the new contract.
- If the IBM check changes the engine's slack placement: engine fix + register entry in the same PR.
Scope: frontier (no burned program needs it; focus lock applies).
🤖 Generated with Claude Code
- Ngôn ngữ chính
- Python
- Star
- 57
- Fork
- 11
- Merge trung bình
- 1 giờ 22 phút
- Pull request đã merge (30 ngày)
- 965
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của squid-protocol/gitgalaxy
-
bug priority: high scope:core
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
squid-protocol/gitgalaxy#7187 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Vault Sentinel skips .tf, .env, .ini, .toml and other config files, and misses three secret kindsĐang mởbug priority: high scope:core
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
squid-protocol/gitgalaxy#7179 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
COBOL: the main line (PROCEDURE DIVISION code before the first paragraph) has no function_data row, so its size, complexity and calls are missing from every per-function viewCó thể đã có người làm @squid-protocol đã nhận hôm nay. Đang mởbug core-engine
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
squid-protocol/gitgalaxy#7170 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug core-engine performance
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 72/100
squid-protocol/gitgalaxy#7169 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement priority: high scope:infra
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
squid-protocol/gitgalaxy#7155 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của squid-protocol/gitgalaxy
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
vllm-project/vllm#64845 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
dekobon/big-code-analysis#1729 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add `openai_safety_identifier`, the replacement for the `user` field that `openai_user` sendsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
pydantic/pydantic-ai#12091 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100