[C & in generale] Confusione con \r, \n e new line.

[Matrixbob]

Osservando la tabella ASCII mi chiedo se il \n è l'insieme di:
ritorno carrello + new line
oppure no:

http://img337.imageshack.us/img337/1173/untitled1nr3.gif

[ilsensine]

No \n corrisponde solo a LF.

[Matrixbob]

No \n corrisponde solo a LF.
.. e allora come mai oltre a cambiare riga, si mette a scrivere tutto a sinistra?!

A pagina 258 (Appendice B) di "Il linguaggio C", ultima traduzione del libro di BW Kernighan; ISBN: 88-7192-200-X.
Pare dire proprio: Ritorno Carrello + Fine Riga.

[Matrixbob]

In questo script ad esempio:

ovText = "AviSynth Authors:"+chr(13)+
\ "----------------------------"+chr(13)+
\ "Ben Radiak Gould"+chr(13)+
\ "Klaus Post"+chr(13)+
\ "Richard Berg"+chr(13)+
\ "Dividee"+chr(13)+
\ "Ian Brabham"+chr(13)+
\ "David Pierre"+chr(13)+chr(13)+
\ "Thanks to:"+chr(13)+
\ "----------------------------"+chr(13)+
\ "Everyone contributing to the project,"+chr(13)+
\ "Doom9 & team, kwag, stickboy"+chr(13)+
\ ""

#Genero clip vuoto bg della dimensione desiderata con colori YV12
#Colore dello sfondo: azzurro
bg = BlankClip(length=750,width=384,height=288,pixel_type="yv12",fps=25,color=$336699)

#Genero clip di report t_mask autoadattante con colori YV12
t_mask = MessageClip(ovText,384,288,true).converttoyv12().coloryuv(levels="tv->pc")

#Genero clip vuoto t_blank con le proprietà di t_mask, ma di colore diverso
#Colore del testo: argento
t_blank = BlankClip(t_mask, color=$e0e0e0)

#Uno strano overlay
last = overlay(bg, t_blank, mode="blend", mask=t_mask)

#Realizzano lo scroll?!
last = frameevaluate(last, "ol_x_offset = 40")
last = frameevaluate(last, "ol_y_offset = 256 - (current_frame)")

fadeio(15)
converttoyv12()

return last

Quello è il \r, ma lo script va anche a capo. :boh:

[ilsensine]

.. e allora come mai oltre a cambiare riga, si mette a scrivere tutto a sinistra?!

Perché lo schermo non è una stampante? :D

A parte gli scherzi, dipende da come viene implementato. Se apri un file scritto su unix (quindi solo con \n per i fine riga) con il notepad, vedi tutto su una riga. Se lo apri con il wordpad, viene visualizzato correttamente.

Riguardo \r che va anche a capo, non ho mai osservato questo comportamento (almeno sotto linux).

[71104]

@Matrixbob, forse ciò che non sai è che i line terminators sono definiti diversamente nei tre principali sistemi operativi, o famiglie di:

in Windows il terminatore di linea è \r\n
nei Mac è \r
in Linux e altri Unix è \n
Windows per compatibilità ammette anche il singolo \n, ma solo nei programmi CUI (console)

[ilsensine]

nei Mac è \r

:doh:

[Matrixbob]

@Matrixbob, forse ciò che non sai è che i line terminators sono definiti diversamente nei tre principali sistemi operativi, o famiglie di:

in Windows il terminatore di linea è \r\n
nei Mac è \r
in Linux e altri Unix è \n
Windows per compatibilità ammette anche il singolo \n, ma solo nei programmi CUI (console)

... in AVISynth che è 1 script language x Windows?
Quel chr(13) è in ASCII il \r.

Diciamo allora che il codice ASCII è quello che è, poi sarà l'applicazione che usiamo ad interpretarlo a suo modo il byte che trova?!

[andbin]

Osservando la tabella ASCII mi chiedo se il \n è l'insieme di:
ritorno carrello + new line
oppure noAhh .. ma stai usando il mio documento sui codici ASCII. :) ;)

Comunque la risposta è no: carriage return e line feed sono due codici diversi e con significato differente. Come ti è già stato risposto dagli altri, un "newline" è codificato in maniera differente sui vari S.O.
Poi come mandare in output un newline dipende anche dal linguaggio usato. Ad esempio in "C" se metti un \n nella printf, ci pensa la funzione a mandare in output la sequenza di newline corretta per il sistema operativo.

Quindi ad esempio: printf ("Ciao\n"); se compilato su DOS/Win manderà in output Ciao CR LF, se compilato su Linux manderà in output Ciao LF (e con CR sui Mac).

Invece ad esempio con Java se fai: System.out.print ("Ciao\n"); manda in output sempre e solo un LF. Se si vuole mandare in output davvero un newline in modo portabile bisogna usare altri metodi (es. println oppure la proprietà "line.separator").

[Matrixbob]

Ahh .. ma stai usando il mio documento sui codici ASCII. :) ;)
:ave: :nera:

Sempre e dovunque, Andbin.

[71104]

:doh: ehm... non è così...? :stordita:

allora ad aver sbagliato siamo in due, visto che l'ha detto anche andbin :D

[71104]

Quindi ad esempio: printf ("Ciao\n"); se compilato su DOS/Win manderà in output Ciao CR LF, veramente che io sappia manda proprio Ciao\n, solo che come dicevo sopra Windows supporta (solo in CUI) anche il singolo \n per compatibilità.

[andbin]

veramente che io sappia manda proprio Ciao\n, solo che come dicevo sopra Windows supporta (solo in CUI) anche il singolo \n per compatibilità.La sprintf mette nel buffer solo \n ma la printf su DOS\Win manda in output CR+LF. Questo è quanto ho visto su tutti i compilatori Win32 che ho sempre usato (VC++ e BCC per dirne due).

[71104]

giorni fa ho fatto questo programma:

#include <windows.h>

INT main(VOID)
{
CONST TCHAR pszMessage[] = TEXT("Hello world!\n");
HANDLE hStdIn, hStdOut;

DWORD dwDummy;

hStdIn = GetStdHandle(STD_INPUT_HANDLE);
hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);

WriteConsole(hStdOut, pszMessage, sizeof(pszMessage) / sizeof(TCHAR) - 1, &dwDummy, NULL);

ReadConsole(hStdIn, &dwDummy, 1, &dwDummy, NULL);

return 0;
}

il quale funziona perfettamente, il che significa che i LF singoli sono supportati correttamente; ora non vedo perché mai il codice di una printf dovrebbe venire complicato aggiungendo \r ad ogni \n :)
se hai veramente letto sorgenti di printf che lo fanno erano sorgenti scritti male.

[Matrixbob]

Ehm direi che qui il confine tra compilatore/SO/applicazione diventa veramente sottile e sfumato.

Nell'appendice del libro sopra citato dice proprio LF+CR.

Anche da qualche altra parte trovai che x evitare problemi si metteva \r\n.
Ma non ricordo + bene il contesto in cui era.

Nell'altro script language (AVISynth), nel ben mezzo di una stringa ci sbattono l'ASCII di \r.
Ora dato che AVISynth è basato su C perchè fanno dei casini del genere gli autori?!
Dalla versione 2.5.7 è stato inserito il \n. Alleluia.

[andbin]

il quale funziona perfettamente, il che significa che i LF singoli sono supportati correttamente; ora non vedo perché mai il codice di una printf dovrebbe venire complicato aggiungendo \r ad ogni \n :)
se hai veramente letto sorgenti di printf che lo fanno erano sorgenti scritti male.Non è per fare polemiche ma .... rispondi:
a) Cosa c'entra printf (standard) con WriteConsole (e simili, specifiche di Win32)??
b) Come faresti con printf a mandare in output un newline in modo "portabile"??

#include <stdio.h>

int main (void)
{
printf ("Ciao\nProva");
return 0;
}
(con VC++)
prova.exe > prova

http://img224.imageshack.us/img224/7766/newlinewm8.gif

Quindi, secondo te?

[Matrixbob]

http://img20.imageshack.us/img20/7025/stdiohe6.gif

[ilsensine]

ehm... non è così...? :stordita:

Si che è così, non ricordavo che i Mac -- come al solito -- thinkasserto differentemente :D

[71104]

a) Cosa c'entra printf (standard) con WriteConsole (e simili, specifiche di Win32)?? come si implementa una printf? se non è WriteConsole è WriteFile.

b) Come faresti con printf a mandare in output un newline in modo "portabile"?? \n

#include <stdio.h>

int main (void)
{
printf ("Ciao\nProva");
return 0;
}
(con VC++) non so cosa tu abbia fatto e non conosco quel programma (Cygnus), ma è assolutamente impossibile che la stringa "Ciao\nProva" nell'eseguibile venga codificata con un carattere in più. giusto per scrupolo ho anche provato a compilare quel programma con Visual C++ 2005, e come immaginavo quella stringa risulta contenere solamente il carattere LF.

[andbin]

come si implementa una printf? se non è WriteConsole è WriteFile.Beh intanto (e indipendentemente dal sistema operativo) la printf non è un "banale" wrapper per una funzione nativa del S.O. È ... molto di più ... pensa solo alla gestione degli specificatori di formato.
Poi su Win32 che funzione nativa venga usata per mandare in output i caratteri non lo so ....
Quello che so è che su Win32, quando la printf incontra un \n manda in output CR+LF.

non so cosa tu abbia fatto e non conosco quel programma (Cygnus), ma è assolutamente impossibile che la stringa "Ciao\nProva" nell'eseguibile venga codificata con un carattere in più. giusto per scrupolo ho anche provato a compilare quel programma con Visual C++ 2005, e come immaginavo quella stringa risulta contenere solamente il carattere LF.Ma LOL :D

"Ciao\nProva" è una stringa literal, nel caso tu non l'abbia notato. Vuol dire che nell'eseguibile è così come è, senza alcun carattere aggiuntivo (perché mai il compilatore dovrebbe aggiungere dei caratteri??). Cioè nell'eseguibile tra Ciao e Prova c'è il carattere 0Ah e basta. E questo varrebbe su qualunque altro S.O.

È la printf che su DOS\Win quando trova un \n manda in output CR+LF. :rolleyes:

[71104]

Quello che so è che su Win32, quando la printf incontra un \n manda in output CR+LF. WriteConsole o WriteFile, per forza.

"Ciao\nProva" è una stringa literal, nel caso tu non l'abbia notato. Vuol dire che nell'eseguibile è così come è, senza alcun carattere aggiuntivo (perché mai il compilatore dovrebbe aggiungere dei caratteri??). Cioè nell'eseguibile tra Ciao e Prova c'è il carattere 0Ah e basta. E questo varrebbe su qualunque altro S.O. e allora spiegami a che serve Cygnus :Prrr:

È la printf che su DOS\Win quando trova un \n manda in output CR+LF. :rolleyes: guarda, prova con un API Tracer a leggere il parametro che viene passato alla chiamata a WriteConsole o WriteFile che sia, e fammi sapere: se gli arriva un \r\n allora è una printf del cazzo :D

[Matrixbob]

È la printf che su DOS\Win quando trova un \n manda in output CR+LF. :rolleyes:
Mi sembra la cosa + plausibile.
Diciamo che è il compilatore C x Windows che compila così.

Altro domandone:
Aprendo alcuni file prodotti con Linux, mi pare, trovo a fine riga qualcosa del tipo:
^M

Che cavolo è quella roba?!

[71104]

Mi sembra la cosa + plausibile.
Diciamo che è il compilatore C x Windows che conpila così. ebbene no, non è così: si verifica facilmente con un editor esadecimale e l'ha detto anche andbin stesso

[Matrixbob]

ebbene no, non è così: si verifica facilmente con un editor esadecimale e l'ha detto anche andbin stesso

Allora son tonto e non capisco, mi riassumi la conclusione a cui siamo giunti?!:stordita:

[71104]

Allora son tonto e non capisco, mi riassumi la conclusione a cui siamo giunti?!:stordita: andbin credo voglia dire che la printf piglia tutti i \n e li sostituisce con \r\n. io dico di no: dico che qualsiasi implementazione di printf per Windows manda i \n così come sono alla WriteConsole o WriteFile, e che CSRSS.EXE quando incontra un \n va semplicemente a capo; ma lo fa anche quando incontra un \r\n.

PS: io stesso ho realizzato una mia versione della printf, esercizio assegnatomi dal professore di Sistemi Operativi 2, e funzionava perfettamente senza sostituire alcunché di newlines ;)
d'accordo che era basata su putchar, ma adesso mi vorreste dire che se putchar riceve '\n' manda "\r\n"?? direi che stiamo esagerando :D

[Matrixbob]

andbin credo voglia dire che la printf piglia tutti i \n e li sostituisce con \r\n. io dico di no: dico che qualsiasi implementazione di printf per Windows manda i \n così come sono alla WriteConsole o WriteFile, e che CSRSS.EXE quando incontra un \n va semplicemente a capo; ma lo fa anche quando incontra un \r\n.

PS: io stesso ho realizzato una mia versione della printf, esercizio assegnatomi dal professore di Sistemi Operativi 2, e funzionava perfettamente senza sostituire alcunché di newlines ;)
d'accordo che era basata su putchar, ma adesso mi vorreste dire che se putchar riceve '\n' manda "\r\n"?? direi che stiamo esagerando :D

Ma guarda che anche l'autorevole testo che ho postato dice ualcosa a riguardo di \n -> \r+\n

[71104]

Ma guarda che anche l'autorevole testo che ho postato dice ualcosa a riguardo di \n -> \r+\n a me non dice niente: "An environment may need to convert a text stream to or from some other representation". quale "environment"? "convertire" a quale stadio dell'I/O?

[ilsensine]

a me non dice niente: "An environment may need to convert a text stream to or from some other representation". quale "environment"? "convertire" a quale stadio dell'I/O?
Credo che avvenga a livello FILE *.
Ricorda il secondo parametro della fopen:
FILE *fopen(const char *path, const char *mode);

"mode" per i file in scrittura può essere "w" o "wb". Sotto linux sono equivalenti, ma scommetto che su windows determinano o meno se la aggiunta di \r è attiva...

La WriteFile non dovrebbe fare nessuna trasformazione credo.

[71104]

Credo che avvenga a livello FILE *.
Ricorda il secondo parametro della fopen:
FILE *fopen(const char *path, const char *mode);

"mode" per i file in scrittura può essere "w" o "wb". Sotto linux sono equivalenti, ma scommetto che su windows determinano o meno se la aggiunta di \r è attiva... plausibile in effetti, comunque prima si parlava specificamente di printf, quindi I/O sulla console. secondo me la console supporta semplicemente i \n singoli (anzi senza il "secondo me" visto che ho provato e funziona). quando si dice che in Windows i terminatori di linea sono composti da \r+\n ci si riferisce principalmente alla GUI: \n scritto in una finestra della classe EDIT appare come un quadratino.

La WriteFile non dovrebbe fare nessuna trasformazione credo. infatti non ne fa: piglia il contenuto del buffer della dimensione specificata e lo sbatte pari pari a quell'HANDLE.

[ilsensine]

plausibile in effetti, comunque prima si parlava specificamente di printf, quindi I/O sulla console.
Stessa cosa, printf equivale a fprintf(stdout, ...)

Non ti è mai capitato di reindirizzare le varie printf su file con un semplice freopen("outfile", "w", stdout)? Funziona anche su windows.

[repne scasb]

andbin credo voglia dire che la printf piglia tutti i \n e li sostituisce con \r\n. io dico di no:


* File Edit View Run Breakpoints Data Options Window Help READY
╔═[■]═CPU 80486═══════════════════════════════════ds:FEA0 = 00Ð═══════3════[↕]═╗
║ cs:13A2 FF4EFE dec word ptr [bp-02] ▲ ax FE0A │c=0║
║ cs:13A5 8B5EFA mov bx,[bp-06] ■ bx FF52 │z=1║
║ cs:13A8 FF46FA inc word ptr [bp-06] ▒ cx 0001 │s=0║
║ cs:13AB 8A07 mov al,[bx] ▒ dx 0004 │o=0║
║ cs:13AD 8846FD mov [bp-03],al ▒ si FEA0 │p=1║
║ cs:13B0 3C0A cmp al,0A ▒ di 0001 │a=0║
║ cs:13B2 7504 jne 13B8 ▒ bp FF24 │i=1║
║ cs:13B4►C6040D mov byte ptr [si],0D ▒ sp FE98 │d=0║
║ cs:13B7 46 inc si ▒ ds 569F │ ║
║ cs:13B8 8A46FD mov al,[bp-03] ▒ es 569F │ ║
║ cs:13BB 8804 mov [si],al ▒ ss 569F │ ║
║ cs:13BD 46 inc si ▒ cs 5556 │ ║
║ cs:13BE 8D8678FF lea ax,[bp-0088] ▒ ip 13B4 │ ║
║ cs:13C2 8BD6 mov dx,si ▒ │ ║
║ cs:13C4 2BD0 sub dx,ax ▼ │ ║
Ã◄■▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒►┼────────────┴───Â
║ ds:FF4F 69 61 6F 0A 00 00 00 00 iao◙ │ ss:FEA0 0000 ║
║ ds:FF57 00 00 00 00 00 00 00 00 │ ss:FE9E 6F61 ║
║ ds:FF5F 00 00 00 00 00 00 00 00 │ ss:FE9C 6943 ║
║ ds:FF67 00 00 00 00 00 00 00 00 │ ss:FE9A 00B0 ║
║ ds:FF6F 00 00 00 00 00 00 00 00 │ ss:FE98►00C8 ║
╚═════════════════════════════════════════════════════════════¤═══════════════─┘
F1-Help F2-Bkpt F3-Mod F4-Here F5-Zoom F6-Next F7-Trace F8-Step F9-Run F10-Menu


E dici male. A 13B4h c'e', il workaround citato da andbin su borland c++ 3.1, lo stesso lo puoi trovare su VC++, WC++.... Prima di cianciare a destra e a manca, dagliela un'occhiata con un debugger ad una printf :rolleyes:

EDIT: Giusto per completezza, perche' sono sicura che dirai che il compilatore che ho usato non e' un compilatore o che il DOS non si usa piu', o che :blah: :blah: ti allego lo stesso workaround per WC++_Win32 su WD @00402DC0.


File Run Break Code Data Undo Search Window Action Help
│■│ Assembly: fputc ││││
001B:00402DC0 fputc_+00000060 
[ ]00402DB6 test al,40
[ ]00402DB8 jne 00402DE1
[ ]00402DBA or byte ptr 0D[edx],10 0023:004080BB=32
[ ]00402DBE mov eax,dword ptr [edx] 0023:004080AE=003606D4▒
==>00402DC0 mov byte ptr [eax],0D 0023:003606D4=20
[ ]00402DC3 mov ebp,dword ptr [edx] 0023:004080AE=003606D4
[ ]00402DC5 inc ebp
[ ]00402DC6 mov eax,dword ptr 04[edx] 0023:004080B2=00000004
[ ]00402DC9 mov dword ptr [edx],ebp 0023:004080AE=003606D4─
▒ │
┌─CPU registers (Pentium Pro)──┐┌─────────┤ Watches ├──────────┐┌─┤ Modules ├──┐
│EAX:003606D4 EBX:00000600 ││ ││[s]prova │
│ECX:0000000A EDX:004080AE ││ ││ │
│ESI:00401540 EDI:00408009 ││ ││ │
│EBP:0006FE64 ESP:0006FD9C ││ ││ │
│EIP:00402DC0 EFL:00000202 ││ ││ │
│C: 0 P: 0 ││ ││ │
│A: 0 Z: 0 ││ ││ │
│S: 0 I: 1 ││ ││ │
│D: 0 O: 0 ││ ││ │
└──────────────────────────────┘└──────────────────────────────┘└──────────────┘

[Matrixbob]

Mamma mia mi si rizzano i peli sulla schiena! :sofico:
Gran thread!
Buona e bella partecipazione.
:)

CMQ prima della sua conclusione mi servirebbero 2 risposte:

1] Cosa è quel ^M che mi è capitato di vedere in file di testo da Unix like a MS like?!

2] In quello script di AVISynth secondo voi il chr(13) alias \r chi è ad interpretarlo?!

[ilsensine]

1] Cosa è quel ^M che mi è capitato di vedere in file di testo da Unix like a MS like?!
^M = ctrl+M = 13. Corrisponde appunto a '\r'.

[Matrixbob]

^M = ctrl+M = 13. Corrisponde appunto a '\r'.
Come hai fatto a capirlo?!
Così la prossima volta non chiedo più. :stordita:

[andbin]

Come hai fatto a capirlo?!Fai un semplice programmino:
#include <stdio.h>
#include <conio.h>

int main (void) {
printf ("cod: %d\n", getch ());
return 0;
}Lancia e premi CTRL+M e vedi che codice ti stampa. ;)

[71104]

premesso che ho capito il motivo percui qualsiasi implementazione di printf su Windows abbia ragione di mandare in output \r\n anziché \n...

E dici male. A 13B4h c'e', il workaround citato da andbin su borland c++ 3.1, lo stesso lo puoi trovare su VC++, WC++.... ... non avendo ne' Borland C++ 3.1 lo "screenshot" che hai postato non mi dice nulla, non riesco neanche a capire se si tratta della printf, di qualche altra funzione standard del C, o di un programma che hai scritto tu.

Prima di cianciare a destra e a manca, dagliela un'occhiata con un debugger ad una printf :rolleyes: sai, che tu ce l'abbia con me per qualche misteriosa ragione me ne frega suppergiù un emerito cazzo :read:

anche andbin poi mi è sembrato piuttosto flame-prone... :mbe:

ma aldilà di questo non l'ho fatto perché avendo installato un Platform SDK per Windows Server 2003 R2 scaricato a parte i sorgenti della printf di Microsoft non mi si sono associati al runtime di Visual C++, e quindi il debugger mi mostra solo assembly. se tu riesci a fare step-by-step fino al punto dove un \n viene sostituito con \r\n bella per te: io non ci riesco -- non in tempi ragionevoli.

si, si, lo so: :blah: :blah:

EDIT: Giusto per completezza, perche' sono sicura che dirai che il compilatore che ho usato non e' un compilatore o che il DOS non si usa piu', o che :blah: :blah: ti allego lo stesso workaround per WC++_Win32 su WD @00402DC0. non ho neanche questo "WC++_Win32 su WD", anche se almeno ora sappiamo che si tratta di fputc. ma giusto per curiosità, perché continui a chiamarlo "workaround"?

[71104]

ma giusto per curiosità, perché continui a chiamarlo "workaround"? ma anzi, guarda, non mi interessa saperlo; evita di rispondermi ancora, chè ultimamente i tuoi post stracciano le palle.

[PGI-Bis]

Se ci fosse una discussione sullo yogurt io scommetto che riuscireste a prendervi a sassate pure su quello :D.

[repne scasb]

.:blah::blah:
.:blah::blah:
.:blah::blah:
.:blah::blah:
.:blah::blah:
.:blah::blah:
.:blah::blah:
.:blah::blah:
.:blah::blah:
.:blah::blah:

[repne scasb]

Se ci fosse una discussione sullo yogurt io scommetto che riuscireste a prendervi a sassate pure su quello.

Sto imparando una nuova arte, grazie alla frequentazione di un oscuro forum.

[repne scasb]

cazzo
palle

Questa e' propaganda politica! Come da regolamento, sezione 1.2 sottosezione e) sono obbligata a segnalarti (1.4.a). :read:

[PGI-Bis]

Hey, se (non ricordo-non ho capito) male:

auguri, Repne Scab

se (ricordo-ho capito) male, allora ho appena fatto una figura di... :D.

[repne scasb]

Hey, se (non ricordo-non ho capito) male:

auguri, Repne Scab

se (ricordo-ho capito) male, allora ho appena fatto una figura di... :D.

:angel: :D

Ricordi bene, e grazie per gli auguri.

[cionci]

non ho neanche questo "WC++_Win32 su WD", anche se almeno ora sappiamo che si tratta di fputc. ma giusto per curiosità, perché continui a chiamarlo "workaround"?
Perché è un'eredità del DOS che io sappia...tra l'altro è una delle prime cose che si impara programmando in ASM se si vuole mandare a capo. E' da eoni che tutti i compilatori C per DOS/Windows si comportano in questo modo.
anche andbin poi mi è sembrato piuttosto flame-prone... :mbe:
Non mi sembra, ha solo tentato di spiegarti in diversi modi quello che non sapevi.
Perché questa è una cosa che non sapevi: e te lo dico senza speranza che tu capisca, nonostante tu abbia una notevole preparazione ci sono ancora molte cose dell'informatica che non conosci e che magari imparerai solo con l'esperienza, ma mai saprai tutto di tutto.
Ogni tanto fa bene anche ammettere le proprie lacune, evitando di arrampicarsi sugli specchi difendendo ad oltranza l'indifendibile.
Come direbbe Sacchi: umilté. Non fa mai male. A nessuno.

[jappilas]

Perché è un'eredità del DOS che io sappia...tra l'altro è una delle prime cose che si impara programmando in ASM se si vuole mandare a capo. E' da eoni che tutti i compilatori C per DOS/Windows si comportano in questo modo.
....
ma mai saprai tutto di tutto.ametto che del workaround trasparente sulla printf non ero a conoscenza, o non avevo fatto caso, nemmeno io... in effetti sulla programmazione assembly ho delle notevoli lacune :( :fagiano:
Come direbbe Sacchi: umilté. Non fa mai male. A nessuno.vero... certo che una straordineria umiltè come la sua è difficilmente eguagliabile :O

[cionci]

NewLine db 0Dh, 0Ah, '$'

Questo era la classica stringa che si metteva nei programmi assembler per andare a capo. Anche perchè i due caratteri erano applicati alla lettera in DOS:
Line Feed: avanzamento di linea <---va alla linee successiva, stessa colonna
Carriage Return: ritorno carrello <---va all'inizio della linea corrente

[71104]

Hey, se (non ricordo-non ho capito) male:

auguri, Repne Scab

se (ricordo-ho capito) male, allora ho appena fatto una figura di... :D. ora capisco: per festeggiare si è ubriacata e si è data alla vita pazza e sfrenata spammando su un forum :asd:

in realtà ha sbagliato festa: per lei c'è la festa del bot :O
ciò implica che hai fatto la tua FDM :read: :Prrr:

[71104]

.:blah::blah:
.:blah::blah:

<e così via per una dozzina di volte>

non ricordo di aver detto punto, punto, punto, punto, punto, punto, punto, punto, punto, punto. :mbe:
ah, ci sono :huh: mi hai quotato punto per punto :asd:

no re thx :|