Programowanie w systemie UNIX/Memory: Różnice pomiędzy wersjami

Usunięta treść Dodana treść
m endianess
interpunkcja, <code>, literówka
Linia 1:
 
=Limity=
Sprawdzamy limity <ref>[http://stackoverflow.com/questions/18371584/size-limit-of-an-array-in-gcc Size limit of an Array in gcc]</ref> za pomocą komendy [[Bash]]a :<ref>[http://ss64.com/bash/ulimit.html ulimit - opis]</ref>
 
ulimit -a
 
Przykładowy wynik :
 
<pre>
Linia 28:
=Pamięć a programowanie =
 
W uproszczeniu z punktu widzenia programisty pamięć<ref>[http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/ Anatomy of a Program in Memory by Gustavo Duarte Jan 27th, 2009 ]</ref><ref>[http://people.redhat.com/drepper/cpumemory.pdf What Every Programmer Should Know About Memory by Ulrich Drepper]</ref> jest podzielona na :<ref>[http://www.inf.udec.cl/~leo/teoX.pdf|Memory management in C: The heap and the stack by Leo Ferres]</ref><ref>[http://www.geeksforgeeks.org/memory-layout-of-c-program/Memory Layout of C Programs]</ref>
* stos ( ang. stack)<ref>[[w:Stos (informatyka)|Stos w wikipedii]]</ref>
* sterta, kopiec lub stóg ( ang. heap)<ref>[[w:Kopiec (informatyka)|Kopiec w wikipedii]]</ref>
 
 
Linia 43:
|}
 
Błędne wykorzystanie pamięci powoduje :<ref>[[w:en:Memory_safety| Bezpieczeństwo pamięci w ang. wikipedii]]</ref>
* Przepełnienie bufora<ref>[[w:Przepełnienie bufora|Przepełnienie bufora]]</ref>
** przepełnienie bufora stosu<ref>[http://duartes.org/gustavo/blog/post/epilogues-canaries-buffer-overflows/ Epilogues, Canaries, and Buffer Overflows by Gustavo Duarte Mar 19th, 2014]</ref>
* przepełnienie sterty
* wycieki pamięci ( wykrywniewykrywanie za pomocą [[Programowanie_w_systemie_UNIX/Valgrind|Valgrinda]])<ref>[http://www.cprogramming.com/debugging/valgrind.html Użycie Valgrinda do wykrywania wycieków pamięci ]</ref>
 
i może powodować zagrożenia informatyczne <ref>[[w:Bezpieczeństwo teleinformatyczne|Bezpieczeństwo teleinformatyczne]]</ref>
 
== Porządek bajtów i bitów (ang. byto order = endianess )==
 
Wiesz zapewne, że podstawową jednostką danych jest bit, który może mieć wartość 0 lub 1. Kilka kolejnych bitów<ref>Standard wymaga aby było ich co najmniej 8 i liczba bitów w bajcie w konkretnej implementacji jest określona przez makro CHAR_BIT zdefiniowane w pliku nagłówkowym limits.h</ref> stanowi bajt (dla skupienia uwagi, przyjmijmy, że bajt składa się z 8 bitów). Często typ short ma wielkość dwóch bajtów i wówczas pojawia się pytanie w jaki sposób są one zapisane w pamięci - czy najpierw ten bardziej znaczący - '''big-endian''', czy najpierw ten mniej znaczący - '''little-endian'''.
Linia 59:
Sprawa się jeszcze bardziej komplikuje w przypadku typów, które składają się np. z 4 bajtów. Wówczas są aż 24 (4 silnia) sposoby zapisania kolejnych fragmentów takiego typu. W praktyce zapewne spotkasz się jedynie z kolejnościami big-endian lub little-endian, co nie zmienia faktu, że inne możliwości także istnieją i przy pisaniu programów, które mają być przenośne należy to brać pod uwagę.
 
Poniższy przykład dobrze obrazuje oba sposoby przechowywania zawartości zmiennych w pamięci komputera (przyjmujemy <code>CHAR_BIT == 8</code> oraz <code>sizeof(long) == 4</code>, bez bitów wypełnienia (ang. ''padding bits'')): <tt>unsigned long zmienna = 0x01020304;</tt> w pamięci komputera będzie przechowywana tak:
adres | 0 | 1 | 2 | 3 |
big-endian |0x01|0x02|0x03|0x04|
little-endian |0x04|0x03|0x02|0x01|
 
Zobacz :
* sprawdzanie za pomocą [[Bash#System|lscpu]]
* k[[C/Przenośność_programów#Konwersja_z_jednego_porz.C4.85dku_do_innego|onwersjekonwersje w C]]