[Gelistirici] Smash that stack harder aka Pardus 2008 C(XX)FLAGS

[S.Çağlar Onur]

03 Şub 2008 Paz tarihinde, Huseyin Akcan şunları yazmıştı: 
> >  Not: Arada kötü yazılmış kodlarda da performans artışı getirdiği de
> > oluyor tabi :) Bakınız [1] ve gereksiz allocate edilmiş 128 byte,
> > yaklaşık 10% performansı arttı, ama bu bir kıstas değil tabi ki, tek
> > fonksiyon tek çağrı tek yerel char array vs.
> >
> > [1] http://cekirdek.pardus.org.tr/~onur/code/exectime_count.c
> 
> Ben burda neden performans artışı oluyor anlamadım,
>     char buf[128];
>     veya char buf[11]
>      veya sadece
>     return strncmp("1234567890", "1234", 4);
> 
> ile hep aynı sonuçları alıyorum süre olarak. Tam süre her denemede
> biraz dalgalanıyor,
> ama minimumları aynı.
> gcc -O2 -D_FORTIFY_SOURCE=2 ile.
> 
> Merat ettim birşey mi kaçırıyorum, neden buf[128] daha hızlı çalışsın
> ki, ortada bellek/cpu hızını ilgilendiren bir kıstas yok. Ne kadar
> bellek kullanılırsa kullanılsın strcpy 11, strncmp 4 karakter sonra
> çalışmasını bitiriyor.

Birşey kaçırmıyorsam bu örnek yanlış zaten

int test() {
    char buf[128];
    strcpy(buf, "1234567890");
    return strncmp(buf, "1234", 4);
}

bu fonksiyonda -fstack-protector'ın kontrol için bir şey değiştirmesi gerekmiyor, bir buffer overflow bu kod ile söz konusu değil ve uzunluk kontrolleri zaten compile time sırasında halledilecek. Örneğin bu fonksiyon şu şekilde değiştirilirse

int test(char *str) {
    char buf[128];
    return sprintf(buf, "%s", str);
}

O zaman compiler araya girecek ve buf öncesine rastgele bir değişken tanımlayacak fonksiyon çıkışında da kontrol edecek.

-- 
S.Çağlar Onur <caglar at pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20080203/c2106997/attachment-0002.pgp>