packz

Quello che segue è un esempio di codice in cui viene utilizzato l'output di un programma come input di quello principale; viene utilizzato un sistema di pipe(7) per far comunicare la coppia di processi che si originano in seguito ad una fork(2): in particolare questo programma prende come argomento il nome di un file e ne restituisce il checksum effettuatto attraverso il commando da shell md5sum(1). Il codice lo trovate qui.

Quest'altro invece mette in risalto una caratteristica di un sistema operativo nel trattare i file descriptor, cioè gli indici che internamente vengono usati per tenere conto dei file aperti; i file descriptor sono molto importanti siccome nella filosofia degli Unix è che ogni cosa è vista come un file ed in particolare ogni programma al suo avvio ha almeno tre file descriptor (o stream nella terminologia dell'ANSI C) lo standard input, output ed error. Il problema che si può avere è che chiudendo questi file descriptor all'avvio del programma, un eventuale successiva apertura di un file andrebbe ad occupare quelli che precedentemente erano collegato con gli stream standard citati precedentemente (il sistema restituisce il primo file descriptor libero) e se magari avete una routine di logging che cerca di scrivere su qualche stream che pensa aperto, le conseguenze potrebbero essere belle bastarde. Il codice può farvi capire quello che sto cercando di spiegare.

Giornata a base di SSL: volevo scrivere un programma per condividere file con i miei friends direttamente senza passare da chat o cose simile che a colpi di 2KiB/s ci metto un anno a copiarmi i file; inoltre vogliamo mettere la possibilità di creare una connessione criptata con la quale scambiarsi file compromettenti? dopo due giorni di coding selvaggio in cui ho perso la elasticità del cristallino posso condividere questa merda di codice con voi. Il codice è questo (peerssl.tar.gz) decompattate e date make; per usare la versione server dovete creare un certificato chiave privata tramite openssl. Sulla mia debian sono solito eseguire

$ openssl genrsa -out packz-private-key.pem 2048
$ openssl req -new -x509 -key packz-private-key.pem -out packz-certificate.pem -days 1095

Non mi chiedete come si aprono le porte del router che esiste google (anche se io ho un link paura che adesso non ho voglia di cercare).

 Intanto beccatevi una foto dal mio modernissimissimo cellulare fatta sotto i portici della mia angusta città in uno dei pochi momenti di pausa della mia retina

P.S: sono alla seconda lattina di birra di questo fottuto sabato e ho appena ucciso una zanzara di almeno 3cm di raggio che mi svolazzava in casa a colpi di scopa.

Regole da seguire per scrivere codice in C

1. Appena apri un file (sopratutto non tuo) imposta shiftwidth, tabstop ed eventualmente expandtab in maniera adeguata al tuo stile. Eventualmente set list ti può far capire che impostazioni sono state usate.
2. Il preprocessore ti ha fatto conoscere # e ## che sono tue amiche e ci sanno fare.
3. Ricordati che con -llibrary dici al linker che al programma serve la libreria library e con -L eventualmente dove trovarla. Un controllo con ldd non fa mai male.
4. Commenta il codice
5. Commenta il codice
6. Se hai creato una funzione con più di due blocchi distinti mi sa che ti tocca riscriverla.
7. Ricordati di nascondere con static una funzione al mondo esterno.
8. Non sforare le 80 colonne.
9. Sempre sia lodato ulimit -c unlimited.
10. Quando migliori il codice assicurati di non peggiorarlo.
11. I Makefile sono una figata
12. Se il tuo programma prevede di scrivere su file usa full(4) per provare cosa succede nel caso si esaurisca lo spazio su disco (tu ovviamente credevi di aver pensato a tutto!!!).
13. Le mailing list sono tue amiche (magari leggile tramite thunderbird che ha un eccellente sezione sulla iscrizione ai news groups di gmane.org).
14. Se desideri open(2) ma vim ti apre open(1) ricordati di premere '2K'.
15. If a macro contains more than one statement, use a do/while structure to enclose the
    macro. (Don't forget to leave out the semicolon of the statement).
16. gcc -dM -E - < /dev/null può dirti quali sono le macro predefinite nel tuo compilatore preferito.
17. Puoi impostare un campo di una struct tramite per esempio
    variabile_struct = (struct punto){ .x = 10.0 , .y = 14.89 }; secondo me è più leggibile e anche se cambi la definizione della struct non hai bisogno di cambiare l'ordine delle inizializzazioni (e il compilatore non ti avverte!!!).
18. Usa un regola esplicita nel makefile per gli header: file.o: header.h. Altrimenti nella ricompilazione può usare una struct che in realtà è stata ridefinita e il segfault diventa un mistero.

Sto riscrivendo dei miei esempi di codice in C e ho varie routine di X11 da modificare in maniera tale da farle lavorare come librerie shared e poterle condividere facilmente tra i vari programmi che scrivo; visto che ogni volta mi incasino per farle funzionare perché non mi ricordo le flags da passare al compilatore/linker qui metto i miei tricks. Per adesso scrivo questo poi metto apposto tutto (sono reduce da una serata di alcol).

Dalla pagina di manuale di gcc(1)

-llibrary
-l library
           Search the library named library when linking.  (The second
           alternative with the library as a separate argument is only for
           POSIX compliance and is not recommended.)

           It makes a difference where in the command you write this option;
           the linker searches and processes libraries and object files in the
           order they are specified.  Thus, foo.o -lz bar.o searches library z
           after file foo.o but before bar.o.  If bar.o refers to functions in
           z, those functions may not be loaded.

           The linker searches a standard list of directories for the library,
           which is actually a file named liblibrary.a.  The linker then uses
           this file as if it had been specified precisely by name.

           The directories searched include several standard system
           directories plus any that you specify with -L.

           Normally the files found this way are library files---archive files
           whose members are object files.  The linker handles an archive file
           by scanning through it for members which define symbols that have
           so far been referenced but not defined.  But if the file that is
           found is an ordinary object file, it is linked in the usual
           fashion.  The only difference between using an -l option and
           specifying a file name is that -l surrounds library with lib and .a
           and searches several directories.

 

Siccome ero frustrato di non aver la possibilità di visualizzare i vari commit relativi al codice che scrivo e che ripongo nei miei repository git situati sul mio sito, ho deciso di scrivere una pagina in Php che faccia da interfaccia ai repository andando a riscrivere alcune delle routine che usa git; manca ancora il completo supporto per i repository che usano gli oggetti in versione pack, ma per i repository normali come i miei funziona abbastanza bene.

ATTENZIONE: IL CODICE È SCRITTO DA UN MALATO DI MENTE ED EROTOMANE, QUINDI ASPETTATEVI CHE IL VOSTRO SERVER PRENDA FUOCO O CHE MALGIOGLIO PRENDA IL POSSESSO DELLE CPU DEL VOSTRO PORTATILE! IO NON MI ASSUMO NESSUNA REPONSABILITÀ!!!

Per chi vuole provarlo, è possibile visionare anche il codice alla pagina http://www.autistici.org/packz/Project/git-php.php.

Apache è il server web forse più famoso nel mondo dell'open source e vanta fra le sue potenzialità la presenza di un gran numero di moduli tramite cui estendere le possibilità di un server web; alcuni di questi sono molto utili e ben testati come mod_dav, mod_ssl oppure mod_rewrite che è quello che interessa a noi. Poi c'è anche chi crea moduli da fuori di testa (un applauso per baku) (Continua)

La mia quest per la compilazione di Xorg con supporto MPX è senza fine: adesso voglio usare jhbuild che se non altro tiene conto in automatico delle dipendenze (ah... le dipendenze) e permette di gestire anche gli errori di compilazione e la generazione in automatico delle variabili necessarie alla compilazione di progetto ampi come X (è nato come supporto a Gnome); dopo vari segfault del driver della scheda video, adesso mi da un errore su un simbolo indefinito che è stato inserito in evdev da quel mago di Hutterer (uno dei pochi che risponde alle mail di un povero adepto della programmazione come me) e che non risulta in nessun file oggetto compilato e presente nei sorgenti. (Continua)

Nei sistemi Debian di solito i pacchetti inseriscono nella directory /usr/share/doc/${nome-pacchetto} dei file tipo README per conoscere qualcosa a riguardo della documentazione; spesso sono compressi e bisogna usare zcat (versione compressa di cat) ed è uno sbattimento scrivere anche a colpi di tab il path, quindi con la funzione

function doc(){ PatH="/usr/share/doc/$1"; zcat "$PatH/README.gz" || cat "$PatH"/README.Debian || dpkg -L "$1" || dpkg -l $1"*" ; }

si dovrebbe avere all'interno della bash un utile comando per avere subito il README a portata di command line. Ovviamente si può migliorare ma come prima storia non c'è male: prima controlla l'esistenza di REAME.gz, poi README.Debian, poi se questi non esistono ti fa la lista dei file installati nel pacchetto ed infine se neanche questo works allora fa una lista dei pacchetti simili installati (dal comando potete vedere come questo funzioni solo su sistemi debian like con chiavi SSH exploitabili).