Newsgroup: it.comp.lang.c
Titolo: toc toc

 
C'è ancora qualche dev, qui?

 C'è ancora qualche dev, qui?
 
No, che vuoi?
 


Se non sei un dev perché lo vuoi sapere?


M'annoio.
 


Potemmo scrivere una qualche sorta di libreria o wrapper
che possa esser utile ma tu non programmi...

 che possa esser utile ma tu non programmi...# potremmo #


M'annoio queste poche ore, non durera' molto... :-)
Libreria per cosa? O wrapper di quale libreria esistente?


Mah... una tra tante, mi piacerebbe scrivere un wrapper su Windows che 
renda l'accesso alle periferiche compatibile col mondo Linux, in modo 
che si renda disponibile una named pipe che possa essere aperta e 
gestita in modo anologo agli special file che si trovano in Linux sotto 
la directory /dev tramite le system call classiche (open, close, read, 
write, ioctl).
 


Ah! Non ti manca l'ambizione. :-D
 
Se vuoi sviluppare moduli del kernel di GNU/Linux
su windows forse si puo' gia' fare:
 
https://www.codeproject.com/Articles/746134/Creating-a-Linux-Kernel-driver-with-Visual-Studio
 
 
 
 


In realtà mi piacerebbe fare quasi il contrario. Cerco di spiegarmi:
Sto giochicchiando intorno alle chiavette dvb_t usb e mi ero prefisso
di scrivere qualcosa che mi permettesse di estrarre un elenco di
canali televisivi con relativa frequenza del mux ed identificativo
dello stream. Girando per il web ho scoperto che esiste già qualcosa
di simile (come il solito) qui:
https://github.com/stefantalpalaru/w_scan2
 
purtroppo funziona solo sotto linux perché si interfaccia al software
driver attraverso lo special file (ex: /dev/chiavetta_dvb_t) che
sotto Windows non esiste.
Mi piacerebbe scrivere un ?servizio? (non so ancora bene cosa) su
Windows che mi permetta di usare il programma di cui sopra compilandolo 
così com'è o con minime modifiche. Quindi che renda disponibile a
w_scan lo special-file (chiavetta_dvb_t) e che wrappi le richieste
verso il software-driver della chiavetta dvb_t.
So che pare un progetto utopico... ci sto curiosando solo intorno,
per ora.

Il 11/07/22 10:06, jak ha scritto:

basta installare le cygwin e in /dev/ ci sono le periferiche
 
 
 
 
-- 
|___|


Se è per quello, w_scan l'ho provato con linux instalalto su una VM
ma quello che mi piacerebbe evitare è proprio installare un sistema
operativo (e installare cygwin non è molto diverso) per utilizzare
un programma, senza contare che ritengo essere un sfida interessante
realizzare tal progetto. Inoltre non sarei così sicuro che cygwin
renda disponibile un interfaccia per la chiavetta dvb_t nella sua
/dev/. Ad esempio msys2 non lo fa. Si può installare?
Questo io non so.

Il 11/07/22 14:28, jak ha scritto:

cygwin non e' un os
E' un layer (in pratica delle dll) che fornisce  api linux su win
Da bash basta fare un ls -l /dev per vedere i device
 
 
-- 
|___|

 
 
Usavo lo stesso comando quasi 40 anni fa su unix. Certe cose
non cambiano proprio mai ;-D
 
 

Il 12/07/22 00:06, jak ha scritto:

ls -l e' std da almeno 40 anni
Ma sei vuoi reinventare la ruota fai pure
Pero basta che ti fai in win il programma che ti serve usando le dll che 
servono di cygwin
Non serve importare tutto lo cygwin
E ancora,cygwin non  e' quella mostruosità in termini di dimensione che 
vuoi far credere
 
 
-- 
|___|


Ma cosa ti rende così difficile seguire il discorso dal suo inizio?
Chiaccherando con il primo interlocutore ho portato un esempio di
cosa si sarebbe potuto discutere e non ho chiesto a nessuno di aiutarmi
a realizzare ciò di cui ho parlato. Ho solo cercato di ravvivare un
canale usnet ormai muto. Per esser più chiaro, non ho chiesto nessun 
consiglio ed ancor meno ne vorrei da chi, invece di discutere di come 
potrebbe esser realizzato mi consiglia un modo per evitare di 
svilupparlo. Non capisco bene cosa ti sfugga ma in questo canale usnet
si dovrebbe discutere di programmazione e non di come evitare di 
programmare. Aggiungo una cosa che ti è sfuggita nel post precedente:
non credo proprio che cygwin renda disponibile un node per
interfacciasi ad un software driver che gestisce una chiavetta dvb_t
quindi, per ora, la ruota di cui stai parlando è solo una tua opinione.
Quando dici a qualcuno che installando cygwin è possibile accedere ai
driver installati su windows per gestire la chiavetta di cui sopra,
prima dovresti accertarti che sia effettivamete fattibile.

Il 14/07/22 06:47, jak ha scritto:

sei tu che hai scritto questo:
 
Mah... una tra tante, mi piacerebbe scrivere un wrapper su Windows che 
renda l'accesso alle periferiche compatibile col mondo Linux, in modo 
che si renda disponibile una named pipe che possa essere aperta e 
gestita in modo anologo agli special file che si trovano in Linux sotto 
la directory /dev tramite le system call classiche (open, close, read, 
write, ioctl).
 
 
 
Un suggerimento l'ho dato, poi fai tu
 
 
-- 
|___|


Va beh, hai vinto, rinuncio. Evidentemente non riesco a convincerti
che il tuo suggeruimento non funziona e che, in ogni caso,  mi
piacerebbe approfondire ed imparare a scrivere un tool come quello
che ho descritto e non trovare un modo di realizzarlo senza scrivere
una linea di codice.
 
grazie lo stesso.
 
l'argomento ed imparare a scrivere una cosa del genere

 l'argomento ed imparare a scrivere una cosa del genere
 
Visto che c'era qualcuno? :-DDDD
 
Comunque questa domanda forse

 
 
Scusate, il primo messaggio mi e' partito per sbaglio.
 
Dicevo, oltre l'ironia, che la domanda e' molto settoriale e
andrebbe posta piu' su qualche newsgroup in lingua inglese
che tratti di sviluppo di moduli del kernel linux o simili.
 
Mi dispiace ma io non ho le competenze specifiche per rispondere.
 
Sappiamo che il kernel di linux e' scritto in C, cosi' come
le api di windows, ma l'attinenza con il gruppo si ferma un po' qui.
Sarebbe piu' fortuna che altro trovare chi ti risponde in quel merito
(considerando anche che 'sto gruppo e' mezzo morto).
 
Ciao!
 

Il 15/07/22 03:15, LutherBlissett ha scritto:

esiste gia un wrapper tra api unix (le syscall) su kernel nt
Sono appunto le cygwin (come avevo suggerito), che e' un insieme di 
programmi base di unix + qualche dll, il wrapper appunto
 
 
-- 
|___|

Il 15/07/22 01:49, jak ha scritto:

Spiega, perche non funziona ?
Forse sono io che ha capito male quello che vuoi fare
 
 
-- 
|___|


Io? Sai, dovresti prendere in considerazione la carriera politica.
Uno fa una domanda e si ritrova a dover dare una risposta.
Raccontami piuttosto come hai fatto tu a farlo funzionare.
 

Il 15/07/2022 14:43, enoquick ha scritto:

Qualche messaggio fa, ho menzionato msys2 che e la versione 64bit
di msys, il quale e nato da una fork di cygwin e  da  quando  es-
istono  le  rispettive  versioni a 64bit (msys2 e cygwin64) i due
ambienti si sono abbastanza allineati. Per mia  comodita  ho  in-
stallato msys2 anziche cygwin64 ma da cio che ho premesso confido
che gli ambienti siano abbastanza simili.  Ed ecco cosa e  possi-
bile trovare sotto la cartella /dev:
 
crw-rw-rw- 1  13, 254 Jul 15 17:27 clipboard
crw-rw-rw- 1   5, 255 Jul 15 17:34 conin
crw-rw-rw- 1   5, 254 Jul 15 17:34 conout
crw-rw-rw- 1   5,   1 Jul 15 17:34 console
crw-rw-rw- 1  14,   3 Jul 15 17:34 dsp
lrwxrwxrwx 1       13 Jun 30 18:12 fd
crw-rw-rw- 1   1,   7 Jul 15 17:34 full
drwxr-xr-x 1        0 Jun 30 18:12 mqueue
crw-rw-rw- 1   1,   3 Jul 15 17:34 null
crw-rw-rw- 1   5,   2 Jul 15 17:34 ptmx
crw--w---- 1 136,   0 Jul 15 17:34 pty0
crw-rw-rw- 1   1,   8 Jul 15 17:34 random
brw-rw-rw- 2  11,   0 Jul 15 17:34 scd0
brw-rw-rw- 2  11,   1 Jul 15 17:34 scd1
brw-rw-rw- 1   8,   0 Jul 15 17:34 sda
brw-rw-rw- 1   8,   1 Jul 15 17:34 sda1
brw-rw-rw- 1   8,  16 Jul 15 17:34 sdb
brw-rw-rw- 1   8,  17 Jul 15 17:34 sdb1
brw-rw-rw- 1   8,  18 Jul 15 17:34 sdb2
brw-rw-rw- 1   8,  32 Jul 15 17:34 sdc
brw-rw-rw- 1   8,  33 Jul 15 17:34 sdc1
drwxr-xr-x 1        0 Jun 30 18:12 shm
brw-rw-rw- 2  11,   0 Jul 15 17:34 sr0
brw-rw-rw- 2  11,   1 Jul 15 17:34 sr1
lrwxrwxrwx 1       15 Jun 30 18:12 stderr
lrwxrwxrwx 1       15 Jun 30 18:12 stdin
lrwxrwxrwx 1       15 Jun 30 18:12 stdout
crw-rw-rw- 1   5,   0 Jul 15 17:34 tty
crw-rw-rw- 1 117,   0 Jul 15 17:34 ttyS0
crw-rw-rw- 1 117,   2 Jul 15 17:34 ttyS2
crw-rw-rw- 1 117,   3 Jul 15 17:34 ttyS3
crw-rw-rw- 1 117,   4 Jul 15 17:34 ttyS4
crw-rw-rw- 1   1,   9 Jul 15 17:34 urandom
crw-rw-rw- 1  13, 255 Jul 15 17:34 windows
crw-rw-rw- 1   1,   5 Jul 15 17:34 zero
 
Come  puoi  notare  i  node  diponibili sono minimali; clipboard,
null, dischi,terminali e poco altro ma  nulla  che  abbia  a  che
vedere  con  le varie periferiche che io ho inserite su questo pc
(BT, dvb_t, tastiere altenative, joypad, ecc.). Questo  significa
che,  ammesso  si  possa  fare,  per  realizzare cio che desidero
sarebbe necessario, come minimo, installare un qualche  pacchetto
di  cui  non sono a conoscenza per rendere diponibile un node per
la chiavetta dvb_t. Quindi seguire il tuo consuglio  e  limitarmi
ad installare cygwin non mi risolverebbe nulla.
 


Ciao,  ti do ragione in parte. Ho seguito questo NG da quando non
esisteva ancora l'adsl ed era veramente molto attivo ed  interes-
sante fin quando non vi si e riversata un'orda di studenti ed in-
egnanti, i primi che avevano come problema piu comune  non  rius-
cire  ad  usare le printf ed i secondi che facevano capolino solo
per bacchettare chi usava i cast sui valori di ritorno delle mal-
loc  :-D  La conseguenza e stata che quelli bravi si sono, ad uno
ad uno, allonatnati, in seguito  gli  studenti  hanno  finalmente
capito  come  usare la printf e se ne sono andati e gli insegnati
hanno mollato peche non c'era  piu  nessuno  da  bacchettare.  Io
stasso  mi  sono spostato nella versione inglese di questo NG che
per i primi tempi era interessante quanto lo era questo  inizial-
mente...  poi  anche  li  sono sopraggiunti i bacchettatori con i
loro non e ISO, non e standard, non e POSIX (per poi magari usare
'typeof'  che  e  peculiare del gcc e quindi non standard). Sono,
pero, convinto che qualcuno  della  vecchia  guardia  che  faccia
capolino  qui  di tanto in tanto ci sia ancora e non nascondo che
mi piacerebbe veder rifiorire questo NG e questo e il motivo  per
cui, ad intervalli del tutto casuali  provo a lasciare un messag-
gio qui. Nel tempo ho provato anche a seguire stackoverflow ma ho
scoperto  ben  presto che e frquentato prevalentemente da caccia-
tori di like e quando mi son trovato a discutere con un tizio  da
200mila like che sosteneva che
 
char a;
long *p;
p = (long *)&a;
*p = 1;
 
in C e corretto perche 'a' puo contenere quel valore, mi sono de-
moralizzato ed ho chiuso l'account.  Ormai mi sono  convinto  che
l'unico  modo  per  recuperare le informazioni che mi interessano
sia quello di impegnarmi a collaborare in qualche grande progetto
dove   debbano/vogliano   condividere  della  documentazione  che
sarebbe, altrimenti, introvabile... ma non  ho  abbastanza  tempo
per intraprendere una cosa del genere.


Grazie, ho letto, ma non càentra un cazzo con quello che ho scritto.
X-DD
 
 

 
[CUT]
 
 
non c'e che dire, una vera perla di non portabilita
oltre a non vedere il motivo di fare una cosa del genere
visto che basta un char a=0x01 per avere lo stesso risultato
 
 
 
 
 
 
 
 
-- 
|___|
 
 


Stesso risultato? No eh... non ti ci mettere anche tu.
L'asempio che ho riportato è sbagliato.
Sborda palesemente in memoria!
 

Il 16/07/22 09:27, jak ha scritto:

Hai frainteso il significato di "stesso risultato"
Il senso di quel codice e' assegnare 0x01 ad a,questo sarebbe il 
significato a cui mi riferivo
Come ho scritto e' assolutamente non portabile
Ma, e non l'avevo scritto,il piu delle volte sbagliato visto che char ha 
un size di 1 byte  e long  > 1 per cui scrivera su una parte di memoria 
che non ha niente a che vedere con a
Ma potrebbe anche non avere effetti collaterali se una macchina avesse 
un char == 4 byte e long idem
Ecco perche avevo scritto non portabile
 
 
 
 
 
-- 
|___|

 
 
Mi permetto di dissentire su un paio di parti:
- la prima è che la dimansioe dei vari tipi è più dipendente dal
compilatore che dal micro della macchina checché ne diacno vari
insegnanti.
 
- la seconda è che sarei d'accordo se avessi detto che esistono
contesti in cui la dimensione di un int potebbe essere uguale a
quella di un long ma non per il tipo char che è, per definizione
e convenzione, sempre di un solo byte.
 
Un ultimo commento è al fatto che hai sostituito il mio 1 con 0x01.
A meno che tu non ne modifichi la tipologia con un'appendice
(es: 1L), quel valore sarà sempre un intero che subirà un auto-cast
prima dell'assegnazione. Vale anche nel caso della rappresentazione
con singoli apici (es: a = '#').
 

 
 
 
0x01 e' un int per cui verra fatto un cast
Ovvio
Ma questo non d'ha problemi in questo caso
 
 
-- 
|___|


Resta pure della tua opinione. Un concorrente in meno :-D
 

Il 16/07/22 12:47, jak ha scritto:

Non e' una opinione,sono fatti
Qui c'e il ref man
https://www.open-std.org/JTC1/SC22/WG14/www/docs/n2310.pdf
 
 
 
 
 
-- 
|___|


Ci provo ancora... ci sono macchine che possono avere dei byte
che non sono formati da 8 bit. Alcune potebbero avere byte di
32 bit ma questo non vuol dire che  un byte sia composto da 4
byte perché 32 / 8 fa 4 ma semplicemete che un byte è di 32
bit. Siccome per definizione la dimensione di un char è di 1
byte ecco, allora, che puoi trovarti un char di 32 bit ma il
suo sizeof sarà 1 perché è il byte ad essere formato da 32 bit.
 
Poi fatti un giro su google scrivendo "C un char è sempre un byte"
e conta quelli che non sono d'accordo con me e trai le tue
conclusioni.

Il 16/07/22 14:34, jak ha scritto:

Non ho mai scritto che un byte sia composto da bit > 8,anche se in 
passato sono state costruite macchine con byte > 8 bit
E' il char,che e' una cosa diversa dal byte, a cui mi stavo riferendo
Su google possono sparare quello che vogliono,e' lo std ref del C che conta
E lo std ref del C non dice mai che un char sia composto da 8 bit (mica 
per altro esiste la macro CHAR_BIT)
Quello che lo std dice e' che sizeof(char) == 1
Non 1 Byte,ma 1
 
 
-- 
|___|

 quanti bit ha un char
 
Sei sicuro di non averlo mai scritto?
 
Vai a tolleggiare con qualcun altro. Con me hai finito.

Il 17/07/22 00:35, jak ha scritto:

E secondo te in quella frase c'e scritto che un byte != 8 bit ?
 
 
-- 
|___|


Ha ragione Jack, quello che hai scritto, e lo hai scritto,
è scorretto.
 
Il byte puo' essere composto da un numero di bit variabile:
mi pare >= 8. Vedi la define CHAR_BIT in limits.h
 
sizeof(char), d'altra parte, è definito con certezza
che ritorni 1.
 
Ora, qualcuno discuteva pure se questo 1 è da interpretarsi
come la size di 1 char oppure 1 byte.
 
Beh...sizeof() è un operatore che ritorna, per definizione,
il numero di byte.
 
https://en.cppreference.com/w/cpp/language/sizeof
 
 
Ne discende che char, o anche unsigned char, è garantito
che siano grandi un byte. Quanti bit? Vedere la define apposita.
 


Bello quel codicillo, correggimi se sbaglio. Assegna l'indirizzo
di un char allocato sullo stack ad un puntatore a long int (allocato
anche lui sullo stesso stack subito dopo) e poi, bel bello, assegna
l'intero 1 (literal senza specificare e' un int anche in c mi pare)
che verrà implicitamente castato a long prima dell'assegnazione.
A questo punto, in a, potrebbe esserci 1...peccato che  sminchiato
lo stack e in p forse c'e' uno zero, o forse il contrario
(sono solo al secondo caffè), comunque e' un paciugo.
 
Perchè ti sei demoralizzato e hai chiuso l'account?
Non ti fare del sangue marcio, non ne vale la pena.
 
 
 

Ah, e miserialadra, non sarà grave ma
meglio inizializzare sempre le variabili.
 
 

Il 18/07/22 01:55, LutherBlissett ha scritto:

No, sizeof(char) ritorna 1,sempre
Quell'uno non e' il numero di bytes ma la dimensione di un char
Se una macchina avesse un char di 32bit sizeof(char) ritornerebbe sempre 1
Infatti la dimensione di un char non e' garantita 8bit ma >= 8bit 
(infatti esiste la macro CHAR_BITS)
 
 
https://en.wikipedia.org/wiki/C_data_types
 
C'e scritto Minimun size (bits)
 
 
 
https://www.quora.com/Why-is-sizeof-char-used-in-C-code-when-its-redundant
 
 
Some programmers might not be aware that sizeof (char) is 1 by 
definition (even if CHAR_BIT > 8, which is rare but possible).
 
 
 
Quindi su una macchina con char a 32bit e long a 32 bit quel codice non 
darebbe problemi anche se sono d'accordo che e' una schifezza
 
 
 
 
 
 
 
 
-- 
|___|

 (infatti esiste la macro CHAR_BITS)
 
 
Non è il numero di bytes?
 
Dunque qui e' sbagliato:
1) Yields the size in bytes of the object representation of type.
2) Yields the size in bytes of the object representation of the type of 
expression, if that expression is evaluated.
https://en.cppreference.com/w/cpp/language/sizeof
 
 
Dunque qui e' sbagliato anche:
https://docs.microsoft.com/en-us/cpp/c-language/sizeof-operator-c?view=msvc-170
 
The sizeof operator gives the amount of storage, in bytes,...
 
 
https://www.tutorialspoint.com/sizeof-operator-in-c
 
When sizeof() is used with the data types, it simply returns the amount 
of memory allocated to that data type.
 
 
Qui e' interessante, dicono giusto, perche' l'unita' di misura
della memoria e' il byte, ed è anche la massima granularità per
misurarla, ovvero non si puo' allocare meno di un byte o un
suo multiplo intero. (Questo anche se un byte fosse 234321 bit)
 
 
*************** Per finirla una volta per tutte ***************
https://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
 
Paragrafo "6.5.3.4 The sizeof operator", punto 2:
"The sizeof operator yields the size (in bytes) of its operand,..."
 
Siccome sizeof(char) == 1 se ne deduce che il tipo char occupa un
byte di memporia.
 
Mi sa che avevano ragione, pur non trovandomi in accordo con
il modo di porsi di alcuni commentatori di ili, spari cazzate
t'incasini e non lo ammetti.
 
Ora torno nell'oblio, se non fosse per jak non avrei neppure risposto.

 Se una macchina avesse un char di 32bit sizeof(char) ritornerebbe sempre 1
[...]
enoquick, se perdi il filo leggendo la mia risposta qui
e' piu' semplice:
 
https://www.cs.technion.ac.il/users/yechiel/c++-faq/sizeof-is-bytes.html
 
 

Il 18/07/22 10:17, LutherBlissett ha scritto:

ma grazie,ma e' come se fosse una funzione, quella che in c++ e' una 
consteval cioe risolta sempre a compile time
Comunque non cambia il succo del discorso

Lo puoi vedere anche come numero di bytes, ma se una macchina ha 
CHAR_BIT == 32 il byte non e' di 8 bit ma di 32
Allora e' corretto,e deve essere per forza cosi visto che sizeof(char) 
e' sempre 1
Altrimenti,se consideri il byte sempre di 8 bit allora sizeof(char) 
potrebbe avere una storage > 1 byte;  ma questo non puo essere visto che 
ritorna sempre 1
 
 
 
-- 
|___|

Il 18/07/22 10:26, LutherBlissett ha scritto:

E sono d'accordo
Ma quanto e' grande,in bit, un byte ?
 
-- 
|___|

Il 15/07/22 11:01, jak ha scritto:

se l'avessi scritto in modo piu specifico cosa volevi fare avrei potuto 
darti una risposta piu mirata
 
 
-- 
|___|

 Ora torno nell'oblio, se non fosse per jak non avrei neppure risposto.
 
Hahahaha (rofl); sono riuscito ad impietosire il tuo granitico cuore?
 

 
 
No, no. Non sangue marcio, direi piuttosto latte alle ginocchia.

 
 
Ah si, se è possibile sarebbe meglio anche se ormai non c'è compilatore
che non ti avvisi se non vede la variabile almeno una volta a sinistra
di un uguale prima che venga letta, sempre che non abbia i warning
disabilitati.

 No, no. Non sangue marcio, direi piuttosto latte alle ginocchia.
 
E te credo
 
-- 
|___|

 No, no. Non sangue marcio, direi piuttosto latte alle ginocchia.
 
Meglio cosi'.

 Ma quanto e' grande,in bit, un byte ?
 
Ma arrangiati!
 
 

 Comunque non cambia il succo del discorso
 
constexpr casomai.
Nel tuo discorso non c'e' succo.
Mi sa che sei tu a non essere risolto.
 
 

 In p ci finisce zero. ;-)
 
Grande! Peccato che avrei dovuto conoscere di quel sito
6 - 7 mesi fa :-(
Visto che mi sembri preparato avrei una domanda ma per corretezza la
porrò in un nuovo thread giusto per cambiare il titolo perché quello
corrente è veramente poco significativo. In ogni caso spero in
un'opinione tecnica. La intitolerò "allocazioni anonime".
Ti ringrazio, in ogni caso, per la dritta.


Il 19/07/22 01:28, LutherBlissett ha scritto:

consteval, constexpr non e' detto che sia risolta sempre a compile time
 
 
-- 
|___|

 consteval, constexpr non e' detto che sia risolta sempre a compile time
 
Questo è vero, al C++20 non ci pensavo ancora.


Poi parlavamo di C, non fare il furbo prendendomi per
stanchezza e distrazione che sono vecchio.
 

Il 19/07/22 11:15, LutherBlissett ha scritto:

Sei tu che avevi polemizzato su sizeof
Te l'ho solo fatto notare che si poteva vedere come una funzione
Ed in C++ esiste consteval per funzioni valutate solo a compile time
Tutto qui,lo so che e' un ng su c e per questo non ho intenzione di 
discutere di c++
 
 
 
-- 
|___|