Dlaczego nie lubię Giganta? (no. 1)

Niektórzy z uśmieszkiem się patrzą jak widzę moje reakcje na produkty firmy z Redmond. Zastanawiam się czy aby wiedzą skąd takie moje podejście. Otóż produkty same w sobie nie są złe. Sporo rzeczy w programach MS działa całkiem fajnie i niejednokrotnie się przekonałem, że niektóre narzędzia dla developer’ów (choćby debugger MS JavaScript’u) są bardzo wygodne.
Główny problem to polityka tej firmy. Tutaj link do jednego z wielu przypadków o jakich słyszałem. I tak jak to napisał autor tej notki nie wiem w jakim celu MS złożył patent grunt to to.
Mnie też by nie przeszkadzało jakby ktoś coś zaporzyczył (o ile bym nie zastrzegł inaczej) nawet w celu zarobku na pomyśle. Może nawet jakby nie wspomniał nic o autorze to by mnie to nie ruszyło. Ale jak się nie dość, że przywłaszcza sobie pomysł, to jeszcze próbuje (bo intuicja mi mówi, że jeśli tylko zostanie przyznany patent, to jednak zostanie to wykorzystane przeciw BlueJ) ukrócić działania autora to to jest, delikatnie mówiąc, denerwujące. Już pomijając, że to czysta głupota, bo taka osoba może kolejne innowacje trzymać zamknięte głęboko w szafece (tak jak było z niektórymi przemyśleniami i pomysłami pana imieniem Никола Тесла po bataliach o prąd przemienny) i pod wpływem złych doświadczeń nikt się o nich nie dowie (mało kogo stać na patent).

Numerek w tytule sugeruje, że pewnie będą się pojawiać kolejne posty na ten temat.

Enter Valhalla

Jedną z ważniejszych umiejętności przy pisaniu programów jest sprawdzanie czy aby program działa tak jak powinien. Bywają w końcu błędy, które nie powodują wyłożenia się programu od razu tylko musi pochodzić dłuższy czas, a nawet i wtedy wcale nie musi być jednoznaczne, że zatkanie się systemu jest efektem działania naszego programu, a nie jakiegoś innego.
W końcu przy bardziej rozbudowanych programach odkryć wyciek pamięci wcale nie jest łatwo. Szczególnie jak mamy małe strukturki po kilka bajtów przez co nie zwracają na siebie uwagi. Zapomnieć o zwolnieniu takiego ustrojstwa jest dość łatwo. Czasem też się zdarza skorzystać ze zmiennej automatycznej bez jej inicjalizacji co może prowadzić do bardzo nieoczekiwanych rezultatów. Na szczęście mądrzy ludzie wymyślili program, który pomaga w radzeniu sobie w dużym stopniu z wieloma błędami. A nazwali go Valgrind

Wskaźnik na wskaźnik. A po co?

#include
#include 

void func1(int *b){
   b = malloc(sizeof(int));
   *b = 1;

   return;
}

void func2(int **c){
   *c = malloc(sizeof(int));
   **c = 2;

   return;
}

int main(int argc, char **argv){
   int *a = NULL;

   a = (int*) malloc(sizeof(int));
   *a = 0;

   printf("%d\n", *a);

   func1(a);
   printf("%d\n", *a);

   func2(&a);
   printf("%d\n", *a);

   free(a);

   return 0;
}

Odpowiedzi dostarczy analiza tego krótkiego programiku.
Przy okazji ten program zawiera błąd w postaci wycieku pamięci. W drugiej funkcji tracimy wskaźnik na zaalokowaną pamięć nie zwalniając jej.

Malinowa Kraina Jeża

Poniżej zamieszczam efekt skumulowanych czynników:
– czwartkowej pobudki o 0800
– treningu w godzinach od 1900 do 2100 tegoż dnia
– pobudkę o 0700 dnia następnego
– otrzymania przez Agnieszkę nagrody za rebusy w postaci kredek i książeczek rozwijających intelekt dzieci do lat 3
– dania mi przez nią pomysłu na przejrzenie nagród i skorzystanie z otrzymanych przyborów
– obecności na mało porywającym wykładzie z logiki i teorii mnogości

Dopóki kolorowałem wszystko z ogólnie przyjętymi przez naturę normami osoby z najbliższego otoczenia patrzyły się na mnie jak na pięciolatka. Jak został mi już tylko trawnik i złapałem malinową (co by być politycznie poprawnym) kredkę i zacząłam ową barwić grunt od razu rozległo się pytanie: “Co Ty robisz!?”. Nie wiedzieć czemu spodziewałem się takiej reakcji.

Self-DoS

W jaki zręczny sposób zablokować własną stronę? Wystarczy robić drobne poprawki w ramach odpoczynku od nauki. Mniej więcej w taki sposób wykonałem atak DoS na własną stronę.
Na nowym silniku strony Interfaksu zrobiłem system automatycznego odświeżania przy użyciu JavaScript’u. Aktualnie częstotliwość odświeżania to minuta (co którą skrypt w tle sobie ściąga co trzeba zaktualizować i odpowiednie elementy strony modyfikuje). Jednak przy wszelkich przeróbkach na witrynie testowej nie widocznej dla całego świata zewnętrznego ustawiłem sobie ten interwał na 3 sekundy co bym nie musiał czekać minuty po każdej zmianie linijki kodu. W ten sposób po jakiejś drobnej poprawce w ramach mojego wrodzonego roztargnienia na główną stronę poszedł skrypt z tym nadwyraz krótkim (jak się okazało) czasem odświeżania.
Tutaj się zaczęła ta “zabawna” część. Strona co prawda odpowiadała na żądania, ale bardzo wolno. Edycja samego pliku ze skryptem sprawy nie załatwia, bo dopóki człowiek przed przeglądarką nie zmieni/odświeży ręcznie strony to nie ma szans na ściągnięcie zaktualizowanego skryptu i dalej będzie ściągał praktycznie non-stop. Ba, żeby było ciekawiej przeglądarki sobie cache’ują te pliki i jakoś mało je obchodzi zmiana czasu ostatniej modyfikacji czy nawet rozmiaru pliku (jak narazie najbardziej oporna na zmiany była Opera). To jest trochę sytuacja bez wyjścia, bo nie mam jak zatrzymać wykonywania się skryptu w czyjejś przeglądarce.
Skończyło się więc na zablokowaniu funkcji odświeżania po stronie serwera do końca dnia, edycji i zmianie nazwy pliku (to ostatnie już wymusiło na wszystkich przeglądarkach ściągnięcie nowej wersji pliku).

Zmienne globalne w C

Tak jak wcześniej napisałem opiszę swoje doświadczenia z korzystaniem ze zmiennych globalnie dostępnych.
Jeżeli planujemy pisać dłuższe programy dobrze jest wyrobić sobie odpowiednie nawyki. Jednym z nich jest rozważne używanie zmiennych globalnych. To co mnie dziwi w przykładach dawanych na wykładach jest wykorzystywanie do wszystkiego zmiennych globalnych.
Weźmy na przykład jeden z projektów na ćwiczenia z programowania. Napisać stos przechowujący elementy dowolnego typu.
Według podejścia “wykładowego” w programie takim pojawiłaby się zmienna globalna np.

struct {
   int pole1;
   int pole2;
   [...]
} stack;

int stackPop(void *elem){
   /* coś tam pobierającego, wybierającego i usuwającego */

   elem = lastElement
   return 0;
}

int stackPush(void *elem, size_t size){
   /* dodawanie */

   return 0;
}

int main(int argc, char **argv){
   /* tutaj może jakaś inicjalizacja by się pojawiła */

   stackPush(to_add, sizeof(to_add));

   if(stackPop(getEelem) == 0){
      free(getEelem);
   }

   return 0;
}

Teraz wyobraźmy sobie, że przydałoby się w tym samym albo w innym programie stworzyć kilka stosów. Ale jak to zrobić jeżeli funkcje korzystają wprost ze zmiennej globalnej? Ano trzeba wszystko przeedytować na to jak można było na samym początku napisać:

struct stack_struct {
   int pole1;
   int pole2;
   [...]
};

int stackPop(struct stack_struct *stack, void *elem){
   /* coś tam pobierającego, wybierającego i usuwającego */
   elem = lastElement;
   return 0;
}

int stackPush(struct stack_struct *stack, void *elem){
   /* dodawanie */

   return 0;
}

int main(int argc, char **argv){
   /* tutaj może jakaś inicjalizacja by się pojawiła */

   stackPush(stack1, to_add1, sizeof(to_add1));
   stackPush(stack1, to_add2, sizeof(to_add2));
   stackPush(stack2, to_add3, sizeof(to_add3));

   if(stackPop(stack1, getEelem) == 0){
      free(getEelem);
   }

   return 0;
}

Używanie zmiennych globalnych naprawdę bardzo sporadycznie jest przydatne, a jeszcze rzadziej jest potrzebne.
Jeszcze jedna różnica z wykładowymi programami to tak, że ja nie używam typedef’ów. Jedno co moge o takowych powiedzieć to to, że tworzenie typów wskaźnikowych jest głupotą/masochizmem. A jedyna różnica o jakiej wiem pomiędzy

typedef struct {
[...]
} aaa;

a

struct aaa {
[...]
};

jest przyzwyczajenie. Dla mnie czytelniejszy i wygodniejszy jest drugi zapis. Choć może typedef ma jeszcze jakieś ukryte właściwości, o których nie było mi dane do tej pory się dowiedzieć.