Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

det translator: mid-record SYNC slack refused in layout check mode (sibling of #5694)

Abierto
#6,926 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement legacy-modernization priority: low scope:frontier

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 gap 1, 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 LayoutDisagrees in 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

  1. 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).
  2. 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 blockers on the census survey: no LayoutDisagrees row; 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

Lenguaje dominante
Python
Estrellas
57
Forks
11
Merge medio
1 h 15 min
PR fusionados (30 d)
976

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de squid-protocol/gitgalaxy

Todos los issues de squid-protocol/gitgalaxy

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.