toc toc

[jak]

C'è ancora qualche dev, qui?

[LutherBlissett]

On 09/07/2022 18:15, jak wrote:
> C'è ancora qualche dev, qui?

No, che vuoi?

[jak]

Se non sei un dev perché lo vuoi sapere?

[LutherBlissett]

M'annoio.

[jak]

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

[jak]

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

[LutherBlissett]

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

[jak]

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).

[LutherBlissett]

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

[jak]

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.

[enoquick]

Il 11/07/22 10:06, jak ha scritto:

basta installare le cygwin e in /dev/ ci sono le periferiche




--
|___|

[jak]

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.

[enoquick]

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


--
|___|

[jak]

Non ho affermato che lo fosse. Ho solo detto che l'intenzione sarebbe
quella di non installare un pacchetto enorme, sia quasto cygwin
oppure un sistema operativo, solo per far girare un programmino
come w_scan.

> 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

[enoquick]

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


--
|___|

[jak]

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.

[enoquick]

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


--
|___|

[jak]

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

[LutherBlissett]

On 15/07/2022 08:49, jak wrote:
> l'argomento ed imparare a scrivere una cosa del genere

Visto che c'era qualcuno? :-DDDD

Comunque questa domanda forse

[LutherBlissett]

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!

[enoquick]

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


--
|___|

[enoquick]

Il 15/07/22 01:49, jak ha scritto:

Spiega, perche non funziona ?
Forse sono io che ha capito male quello che vuoi fare


--
|___|

[jak]

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.

[jak]

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.

[jak]

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.

[LutherBlissett]

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

[enoquick]

Il 15/07/22 12:10, jak ha scritto:

> Il 15/07/2022 10:15, LutherBlissett ha scritto:
>

[CUT]

> char a;
> long *p;
> p = (long *)&a;
> *p = 1;
>

[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








--
|___|

[jak]

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

[enoquick]

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





--
|___|

[jak]

Il 16/07/2022 18:15, enoquick ha scritto:
> Il 16/07/22 09:27, jak ha scritto:
>> Il 16/07/2022 15:29, enoquick ha scritto:
>>> Il 15/07/22 12:10, jak ha scritto:
>>>> Il 15/07/2022 10:15, LutherBlissett ha scritto:
>>>>
>>> [CUT]
>>>> char a;
>>>> long *p;
>>>> p = (long *)&a;
>>>> *p = 1;
>>>>
>>> [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!
>>
>
> Hai frainteso il significato di "stesso risultato"

Ah, quindi ancora una volta è colpa mia che ho frainteso.
Buono a sapersi.

> 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 = '#').

[enoquick]

Il 16/07/22 12:00, jak ha scritto:

> Il 16/07/2022 18:15, enoquick ha scritto:
>> Il 16/07/22 09:27, jak ha scritto:
>>> Il 16/07/2022 15:29, enoquick ha scritto:
>>>> Il 15/07/22 12:10, jak ha scritto:
>>>>> Il 15/07/2022 10:15, LutherBlissett ha scritto:
>>>>>
>>>> [CUT]
>>>>> char a;
>>>>> long *p;
>>>>> p = (long *)&a;
>>>>> *p = 1;
>>>>>
>>>> [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!
>>>
>>
>> Hai frainteso il significato di "stesso risultato"
>
> Ah, quindi ancora una volta è colpa mia che ho frainteso.
> Buono a sapersi.
>

Che ti metti ora, a fare polemiche?

>> 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.
>

E dipendente dal compilatore e dalla macchina
Ma comunque un compilatore per la macchina X si suppone che usera una
dimensione dei tipi base congruente con l'hw di X anche solo per ragioni
di efficienza
E l'efficienza e' una delle basi di C

> - 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.
>

No, possono esistere macchine che hanno char uguale a 4 byte,almeno
sulla carta
Se in pratica esistono non lo so
lo std C afferma che sizeof(char) <= sizeof(short) <= sizeof(int) <=
sizeof(long), lo std non mette dimensioni al numero di bit di un char
Per cui, almeno sulla carta,e' possibile che un char abbia 4byte
E mica per altro esiste la macro CHAR_BIT in limits.h che specifica
quanti bit ha un char

> 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


--
|___|

[jak]

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

[enoquick]

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




--
|___|

[jak]

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.

[enoquick]

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


--
|___|

[jak]

Il 17/07/2022 03:47, enoquick ha scritto:
> Per cui, almeno sulla carta,e' possibile che un char abbia 4byte
> E mica per altro esiste la macro CHAR_BIT in limits.h che specifica
> quanti bit ha un char

Sei sicuro di non averlo mai scritto?

Vai a tolleggiare con qualcun altro. Con me hai finito.

[enoquick]

Il 17/07/22 00:35, jak ha scritto:

E secondo te in quella frase c'e scritto che un byte != 8 bit ?


--
|___|

[LutherBlissett]

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.

[LutherBlissett]

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.

[LutherBlissett]

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

[enoquick]

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








--
|___|

[LutherBlissett]

sizeof() non ritorna proprio un ..... di niente, sizeof è
un operatore il cui valore è calcolato a tempo di compilazione
e si, sizeof(char) vale sempre 1.

> 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)

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.

[LutherBlissett]

On 18/07/2022 15:53, enoquick wrote:

> Il 18/07/22 01:55, LutherBlissett ha scritto:

[...]

>> 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.
>>
>
>
> 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

[...]
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

[enoquick]

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



--
|___|

[enoquick]

Il 18/07/22 10:26, LutherBlissett ha scritto:

E sono d'accordo
Ma quanto e' grande,in bit, un byte ?

--
|___|

[enoquick]

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


--
|___|

[jak]

Il 18/07/2022 17:17, LutherBlissett ha scritto:
[SNIP]

> *************** Per finirla una volta per tutte ***************

Illuso.
XD

[RI-SNIP]

> Ora torno nell'oblio, se non fosse per jak non avrei neppure risposto.

Hahahaha (rofl); sono riuscito ad impietosire il tuo granitico cuore?

[jak]

Nulla da correggere, l'unico commento è che se si usa il gcc quello che
accade nello stack diventa difficile da dimostrare perché i campi dello
stack son di 4 byte ed i long pure, quindi quando dichiari una variabile
di tipo char, accade che quaesta occupa tutto un campo dello stack ed il
suo indirizzo corrisponde a quello dell'lsb. Quando esegue quella
assegnazione i 4 byte per scrivere ce l'ha (anche se è spazio scatch) e
grazie a 'sta botta di culo, non sborda. Per vedelo sbordare
bisognerebbe far diventare 'a' un array inizializzato significativamente
poi stampare il contenuto prima e dopo l'assegnamento.

>
> Perchè ti sei demoralizzato e hai chiuso l'account?
> Non ti fare del sangue marcio, non ne vale la pena.
>

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

[jak]

Il 18/07/2022 10:03, LutherBlissett ha scritto:
> Ah, e miserialadra, non sarà grave ma
> meglio inizializzare sempre le variabili.
>
>

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.

[enoquick]

Il 18/07/22 15:53, jak ha scritto:

gcc fara cosi,ma quel codice e' assolutamente non portabile
Non c'e solo gcc a questo mondo

> >
>> Perchè ti sei demoralizzato e hai chiuso l'account?
>> Non ti fare del sangue marcio, non ne vale la pena.
>>
>
> No, no. Non sangue marcio, direi piuttosto latte alle ginocchia.

E te credo

--
|___|

[LutherBlissett]

On 18/07/2022 22:53, jak wrote:
> Nulla da correggere, l'unico commento è che se si usa il gcc quello che
> accade nello stack diventa difficile da dimostrare perché i campi dello
> stack son di 4 byte ed i long pure, quindi quando dichiari una variabile
> di tipo char, accade che quaesta occupa tutto un campo dello stack ed il
> suo indirizzo corrisponde a quello dell'lsb. Quando esegue quella
> assegnazione i 4 byte per scrivere ce l'ha (anche se è spazio scatch) e
> grazie a 'sta botta di culo, non sborda. Per vedelo sbordare
> bisognerebbe far diventare 'a' un array inizializzato significativamente
> poi stampare il contenuto prima e dopo l'assegnamento.
>

Prova qui:

https://www.onlinegdb.com/online_c++_compiler

int main()
{

char a;
long *p;
p = (long *)&a;
*p = 1;

return 0;
}

e debugga. A causa di :
*p = 1;

In p ci finisce zero. ;-)

>> Perchè ti sei demoralizzato e hai chiuso l'account?
>> Non ti fare del sangue marcio, non ne vale la pena.
>
> No, no. Non sangue marcio, direi piuttosto latte alle ginocchia.

Meglio cosi'.

[LutherBlissett]

On 18/07/2022 19:30, enoquick wrote:
> E sono d'accordo
> Ma quanto e' grande,in bit, un byte ?

Ma arrangiati!

[LutherBlissett]

On 18/07/2022 17:52, enoquick wrote:
> 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

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

[jak]

Il 19/07/2022 08:22, LutherBlissett ha scritto:
> On 18/07/2022 22:53, jak wrote:
>> Nulla da correggere, l'unico commento è che se si usa il gcc quello che
>> accade nello stack diventa difficile da dimostrare perché i campi dello
>> stack son di 4 byte ed i long pure, quindi quando dichiari una variabile
>> di tipo char, accade che quaesta occupa tutto un campo dello stack ed il
>> suo indirizzo corrisponde a quello dell'lsb. Quando esegue quella
>> assegnazione i 4 byte per scrivere ce l'ha (anche se è spazio scatch) e
>> grazie a 'sta botta di culo, non sborda. Per vedelo sbordare
>> bisognerebbe far diventare 'a' un array inizializzato significativamente
>> poi stampare il contenuto prima e dopo l'assegnamento.
>>
>
>
> Prova qui:
>
> https://www.onlinegdb.com/online_c++_compiler
>
> int main()
> {
>     char a;
>     long *p;
>     p = (long *)&a;
>     *p = 1;
>
>     return 0;
> }
>
> e debugga. A causa di :
>     *p = 1;
>
> 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.

[enoquick]

Il 19/07/22 01:28, LutherBlissett ha scritto:

consteval, constexpr non e' detto che sia risolta sempre a compile time


--
|___|

[LutherBlissett]

On 19/07/2022 17:35, enoquick wrote:
> consteval, constexpr non e' detto che sia risolta sempre a compile time

Questo è vero, al C++20 non ci pensavo ancora.

[LutherBlissett]

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

[enoquick]

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++



--
|___|