[Fikir] Güvenlik ve Stabilite için Java Tarzı Tasarım Kararları (Sınır Kontrolü, Hata İzolasyonu) #109

New Issue

saqut · 2026-06-14T22:26:31+03:00

saqut commented

2026-06-14 22:26:31 +03:00

Giriş (Nedir, Neden Önemli?)

saQut'ta kullanıcıya açık pointer yok (dil kimliği) — bu, C'nin en büyük güvenlik açığı kaynağı olan "pointer aritmetiği"ni baştan eliyor. Ama Java'nın asıl gücü bundan da fazlası: her hata kontrollü bir şekilde yakalanır, programın geri kalanı çökmeden devam edebilir (exception/hata izolasyonu) ve dizi sınırları her zaman kontrol edilir. Bu issue, bu ilkelerin saQut'a nasıl yansıyacağını tartışır.

Gelişme (Tavsiyeler)

Array sınır kontrolü (bounds checking): int[3] notlar; notlar[5] = 1; gibi bir erişim — eğer boyut derleme zamanında biliniyorsa (E009 zaten "array boyutu sabit değil" hatasını kapsıyor, ama "sabit boyut + sınır-dışı indeks" ayrı bir konu) derleme zamanında E0xx ile yakalanmalı; eğer indeks çalışma zamanı değeriyse (notlar[i], i döngü değişkeni), VM çalışma zamanında kontrol etmeli ve kontrollü bir "runtime error" üretmeli (C'deki sessiz bellek bozulmasının tam tersi).
Çalışma zamanı hatalarının kategorize edilmesi: sıfıra bölme (Faz 4'te W002 derleme-zamanı uyarısı var, ama çalışma zamanında gerçek bir bölme 10 / x ile x=0 olursa ne olur?), dizi sınır taşması, derinlik taşması (call stack overflow, #78) — bunların hepsi aynı "RuntimeError" ailesinde, konum bilgisiyle (hangi print/satırda patladı) raporlanmalı; VM segfault ile çökmemeli.
"Programın bir kısmı patlasın, derleyici/VM çökmesin": VM'in kendi C++ kodunda assert/exception kullanımı, kullanıcı programındaki bir hatayı (örn. sınır-dışı erişim) VM crash'ine dönüştürmemeli — bu, VM geliştirilirken her runtime-error noktasında "bu durum kullanıcıya nasıl raporlanır" sorusunun sorulması demektir.
Tip sisteminin sıkılığı (ADR-010) zaten "Java tarzı" bir güvenlik katmanı — gizli dönüşüm yok kuralı, C'deki "implicit int→pointer" gibi klasik hata sınıflarını zaten önlüyor. Bu issue bunu devam ettirme çağrısıdır, yeni bir şey eklemiyor.

Açık Sorular

Çalışma zamanı hataları (array sınır taşması vb.) için yeni bir diagnostic kategorisi (R001, R002... "Runtime" öneki ile, E/W'den ayrı) mı açılmalı — IR/VM tasarım issue'larına (#74-78) not edilmeli.
Sınır kontrolü her zaman mı açık olacak, yoksa "release modu"nda (varsa böyle bir kavram) kapatılabilir mi — ADR-015'in "determinizm > hız" ilkesi düşünülürse, her zaman açık olması daha tutarlı görünüyor.

İmza/Yorum: "Güvenli dil" derken kastedilen genelde "bellek güvenliği" — saQut bunu zaten pointer'sızlıkla büyük ölçüde kazandı; kalan iş, çalışma zamanı hatalarını zarif bir şekilde raporlamak.

### Giriş (Nedir, Neden Önemli?) saQut'ta kullanıcıya açık pointer yok (dil kimliği) — bu, C'nin en büyük güvenlik açığı kaynağı olan "pointer aritmetiği"ni baştan eliyor. Ama Java'nın asıl gücü bundan da fazlası: **her hata kontrollü bir şekilde yakalanır, programın geri kalanı çökmeden devam edebilir** (exception/hata izolasyonu) ve **dizi sınırları her zaman kontrol edilir**. Bu issue, bu ilkelerin saQut'a nasıl yansıyacağını tartışır. --- ### Gelişme (Tavsiyeler) - **Array sınır kontrolü (bounds checking):** `int[3] notlar; notlar[5] = 1;` gibi bir erişim — eğer boyut derleme zamanında biliniyorsa (`E009` zaten "array boyutu sabit değil" hatasını kapsıyor, ama "sabit boyut + sınır-dışı indeks" ayrı bir konu) **derleme zamanında** `E0xx` ile yakalanmalı; eğer indeks çalışma zamanı değeriyse (`notlar[i]`, `i` döngü değişkeni), **VM çalışma zamanında kontrol etmeli** ve kontrollü bir "runtime error" üretmeli (C'deki sessiz bellek bozulmasının tam tersi). - **Çalışma zamanı hatalarının kategorize edilmesi:** sıfıra bölme (Faz 4'te `W002` derleme-zamanı uyarısı var, ama çalışma zamanında gerçek bir bölme `10 / x` ile `x=0` olursa ne olur?), dizi sınır taşması, derinlik taşması (call stack overflow, #78) — bunların hepsi **aynı "RuntimeError" ailesinde**, konum bilgisiyle (hangi `print`/satırda patladı) raporlanmalı; VM **segfault** ile çökmemeli. - **"Programın bir kısmı patlasın, derleyici/VM çökmesin":** VM'in kendi C++ kodunda `assert`/exception kullanımı, kullanıcı programındaki bir hatayı (örn. sınır-dışı erişim) **VM crash'ine** dönüştürmemeli — bu, VM geliştirilirken her runtime-error noktasında "bu durum kullanıcıya nasıl raporlanır" sorusunun sorulması demektir. - **Tip sisteminin sıkılığı (ADR-010) zaten "Java tarzı" bir güvenlik katmanı** — gizli dönüşüm yok kuralı, C'deki "implicit int→pointer" gibi klasik hata sınıflarını zaten önlüyor. Bu issue bunu **devam ettirme** çağrısıdır, yeni bir şey eklemiyor. --- ### Açık Sorular - Çalışma zamanı hataları (array sınır taşması vb.) için **yeni bir diagnostic kategorisi** (`R001`, `R002`... "Runtime" öneki ile, `E`/`W`'den ayrı) mı açılmalı — IR/VM tasarım issue'larına (#74-78) not edilmeli. - Sınır kontrolü **her zaman** mı açık olacak, yoksa "release modu"nda (varsa böyle bir kavram) kapatılabilir mi — ADR-015'in "determinizm > hız" ilkesi düşünülürse, **her zaman açık** olması daha tutarlı görünüyor. *İmza/Yorum:* "Güvenli dil" derken kastedilen genelde "bellek güvenliği" — saQut bunu zaten pointer'sızlıkla büyük ölçüde kazandı; kalan iş, **çalışma zamanı hatalarını zarif bir şekilde raporlamak**.

saqut added the

fikir

kalite-mimari

labels 2026-06-14 22:26:31 +03:00

Sign in to join this conversation.