Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
int main(int argc, char *argv[])
{
int x, y, i;
machin m;
/* remplir le machin */
for (i=0; i<16; i++)
m.l[i] = i;
/* afficher le machin */
for (x=0; x<4; x++)
{
for (y=0; y<4; y++)
printf("%2d ", m.s[x][y]);
puts("");
}
return 0;
}
-----------------------------------------------
Ai-je raison de penser que ces deux façons de voir un bloc de
seize petits nombres est portable sur une grande majorité de
trucs, et que dans les deux cas, je peux supposer que le
compilateur saura faire les optimisations qui vont bien ?
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
int main(int argc, char *argv[])
{
int x, y, i;
machin m;
/* remplir le machin */
for (i=0; i<16; i++)
m.l[i] = i;
/* afficher le machin */
for (x=0; x<4; x++)
{
for (y=0; y<4; y++)
printf("%2d ", m.s[x][y]);
puts("");
}
return 0;
}
-----------------------------------------------
Ai-je raison de penser que ces deux façons de voir un bloc de
seize petits nombres est portable sur une grande majorité de
trucs, et que dans les deux cas, je peux supposer que le
compilateur saura faire les optimisations qui vont bien ?
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
int main(int argc, char *argv[])
{
int x, y, i;
machin m;
/* remplir le machin */
for (i=0; i<16; i++)
m.l[i] = i;
/* afficher le machin */
for (x=0; x<4; x++)
{
for (y=0; y<4; y++)
printf("%2d ", m.s[x][y]);
puts("");
}
return 0;
}
-----------------------------------------------
Ai-je raison de penser que ces deux façons de voir un bloc de
seize petits nombres est portable sur une grande majorité de
trucs, et que dans les deux cas, je peux supposer que le
compilateur saura faire les optimisations qui vont bien ?
Le 29-05-2008, à propos de
Union de deux tableaux 4x4 et 1x16,
Thierry B. écrivait dans fr.comp.lang.c :
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Le 29-05-2008, à propos de
Union de deux tableaux 4x4 et 1x16,
Thierry B. écrivait dans fr.comp.lang.c :
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Le 29-05-2008, à propos de
Union de deux tableaux 4x4 et 1x16,
Thierry B. écrivait dans fr.comp.lang.c :
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
In article ,
JKB wrote:Le 29-05-2008, à propos de
Union de deux tableaux 4x4 et 1x16,
Thierry B. écrivait dans fr.comp.lang.c :
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Cote representation memoire, ca doit marcher, grace aux calculs habituels
de taille de tableau.
Cote aliasing, ca doit marcher aussi, vu que le type final avec lequel tu
joues est un char.
C'est un tantinet beurk, mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
In article <slrng3tk36.il3.knatschke@rayleigh.systella.fr>,
JKB <wilhelm-siegfried.knatschke-koenigsberg@chezmoi.com> wrote:
Le 29-05-2008, à propos de
Union de deux tableaux 4x4 et 1x16,
Thierry B. écrivait dans fr.comp.lang.c :
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Cote representation memoire, ca doit marcher, grace aux calculs habituels
de taille de tableau.
Cote aliasing, ca doit marcher aussi, vu que le type final avec lequel tu
joues est un char.
C'est un tantinet beurk, mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
In article ,
JKB wrote:Le 29-05-2008, à propos de
Union de deux tableaux 4x4 et 1x16,
Thierry B. écrivait dans fr.comp.lang.c :
Bonjour le monde.
Question simple, avec un ECM:
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Cote representation memoire, ca doit marcher, grace aux calculs habituels
de taille de tableau.
Cote aliasing, ca doit marcher aussi, vu que le type final avec lequel tu
joues est un char.
C'est un tantinet beurk, mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
C'est un tantinet beurk,
mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
C'est un tantinet beurk,
mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
C'est un tantinet beurk,
mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
C'est un tantinet beurk,
En quoi c'est beurk ?
mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
Donc, on ne serait pas dans ce cas (extrait de C89, §6.3.2.3)
---------------- 8< -------------------------
With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined.
---------------- >8 -------------------------
C'est un tantinet beurk,
En quoi c'est beurk ?
mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
Donc, on ne serait pas dans ce cas (extrait de C89, §6.3.2.3)
---------------- 8< -------------------------
With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined.
---------------- >8 -------------------------
C'est un tantinet beurk,
En quoi c'est beurk ?
mais je pense que c'est portable sur toutes
les implementations conformes a la norme, en C89 comme C99...
Donc, on ne serait pas dans ce cas (extrait de C89, §6.3.2.3)
---------------- 8< -------------------------
With one exception, if a member of a union object is accessed after
a value has been stored in a different member of the object, the
behavior is implementation-defined.
---------------- >8 -------------------------
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Cote representation memoire, ca doit marcher, grace aux calculs habituels
de taille de tableau.
C'est un tantinet beurk,
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Cote representation memoire, ca doit marcher, grace aux calculs habituels
de taille de tableau.
C'est un tantinet beurk,
-----------------------------------------------
#include <stdio.h>
typedef union
{
char s[4][4];
char l[16];
} machin;
Cote representation memoire, ca doit marcher, grace aux calculs habituels
de taille de tableau.
C'est un tantinet beurk,
Ce n'est pas qosher (strictement conforme si tu préfères).
Marc répond à la question originale, « est-ce que mon truc va marcher sur la
Toi, tu te retranches derrière le texte strict de la norme, qui dit que le
Pour aller plus loin avec le texte que tu cites, comme il s'agit
d'une > «implémentation définie » par l'implémentation (donc documentée et
quelle interprétation proposes-tu pour un hypothétique compilateur («
courrant », ce qui exclut l'hypothèse de Jean-Marc, ou les warnings d'un
splint) qui invaliderait ou même mettrait un bémol sur les hypothèses
originales de Thierry ?
Personnellement, le seul truc qui me chiffonne un peu, c'est si on torture
un peu le bidule avec une architecture de malade genre x86-16 segmentée (et
les pointeurs huge et compagnie), et si on suppose que les tableaux sont
plus grands, en particulier plus grands que 64K, évidemment. Un truc genre
typedef union hugemachin {
char s[6400][16];
char l[102400];
} hugemachin;
Mais même avec des idées tordues dans ce genre, je n'ai pas vu de soucis
avec le code de Thierry, car le fait que ce soit une union va forcer un
compilateur conforme à toujours honorer à la fois les contraintes sur s (qui
doit commencer sur une frontière de 16 octets) et sur l (dont l'arithmétique
doit utiliser les pointeurs huge) ; mais ceci n'est pas contradictoire.
Ce n'est pas qosher (strictement conforme si tu préfères).
Marc répond à la question originale, « est-ce que mon truc va marcher sur la
Toi, tu te retranches derrière le texte strict de la norme, qui dit que le
Pour aller plus loin avec le texte que tu cites, comme il s'agit
d'une > «implémentation définie » par l'implémentation (donc documentée et
quelle interprétation proposes-tu pour un hypothétique compilateur («
courrant », ce qui exclut l'hypothèse de Jean-Marc, ou les warnings d'un
splint) qui invaliderait ou même mettrait un bémol sur les hypothèses
originales de Thierry ?
Personnellement, le seul truc qui me chiffonne un peu, c'est si on torture
un peu le bidule avec une architecture de malade genre x86-16 segmentée (et
les pointeurs huge et compagnie), et si on suppose que les tableaux sont
plus grands, en particulier plus grands que 64K, évidemment. Un truc genre
typedef union hugemachin {
char s[6400][16];
char l[102400];
} hugemachin;
Mais même avec des idées tordues dans ce genre, je n'ai pas vu de soucis
avec le code de Thierry, car le fait que ce soit une union va forcer un
compilateur conforme à toujours honorer à la fois les contraintes sur s (qui
doit commencer sur une frontière de 16 octets) et sur l (dont l'arithmétique
doit utiliser les pointeurs huge) ; mais ceci n'est pas contradictoire.
Ce n'est pas qosher (strictement conforme si tu préfères).
Marc répond à la question originale, « est-ce que mon truc va marcher sur la
Toi, tu te retranches derrière le texte strict de la norme, qui dit que le
Pour aller plus loin avec le texte que tu cites, comme il s'agit
d'une > «implémentation définie » par l'implémentation (donc documentée et
quelle interprétation proposes-tu pour un hypothétique compilateur («
courrant », ce qui exclut l'hypothèse de Jean-Marc, ou les warnings d'un
splint) qui invaliderait ou même mettrait un bémol sur les hypothèses
originales de Thierry ?
Personnellement, le seul truc qui me chiffonne un peu, c'est si on torture
un peu le bidule avec une architecture de malade genre x86-16 segmentée (et
les pointeurs huge et compagnie), et si on suppose que les tableaux sont
plus grands, en particulier plus grands que 64K, évidemment. Un truc genre
typedef union hugemachin {
char s[6400][16];
char l[102400];
} hugemachin;
Mais même avec des idées tordues dans ce genre, je n'ai pas vu de soucis
avec le code de Thierry, car le fait que ce soit une union va forcer un
compilateur conforme à toujours honorer à la fois les contraintes sur s (qui
doit commencer sur une frontière de 16 octets) et sur l (dont l'arithmétique
doit utiliser les pointeurs huge) ; mais ceci n'est pas contradictoire.
Parmi les experts qui fréquentent ce forum, y en aurait-il un qui
pourrait nous copier-coller ce que dit par exemple gcc sur le
comportement défini par l'implémentation de l'ecm du po ?
Parmi les experts qui fréquentent ce forum, y en aurait-il un qui
pourrait nous copier-coller ce que dit par exemple gcc sur le
comportement défini par l'implémentation de l'ecm du po ?
Parmi les experts qui fréquentent ce forum, y en aurait-il un qui
pourrait nous copier-coller ce que dit par exemple gcc sur le
comportement défini par l'implémentation de l'ecm du po ?
----------------------------8<--------------------------------------
4.9 Structures, unions, enumerations, and bit-fields
A member of a union object is accessed using a member of a different
type (C90 6.3.2.3).
The relevant bytes of the representation of the object are treated as an
object of the type used for the access. This may be a trap representation.
---------------------------->8--------------------------------------
Par contre, je n'ai pas vu dans la doc la mention d'un warning ad hoc ?
Toute machine qui se respecte a sa console sur un port serie... :-)
La question n'est pas de savoir si elle a une console sur port série,
----------------------------8<--------------------------------------
4.9 Structures, unions, enumerations, and bit-fields
A member of a union object is accessed using a member of a different
type (C90 6.3.2.3).
The relevant bytes of the representation of the object are treated as an
object of the type used for the access. This may be a trap representation.
---------------------------->8--------------------------------------
Par contre, je n'ai pas vu dans la doc la mention d'un warning ad hoc ?
Toute machine qui se respecte a sa console sur un port serie... :-)
La question n'est pas de savoir si elle a une console sur port série,
----------------------------8<--------------------------------------
4.9 Structures, unions, enumerations, and bit-fields
A member of a union object is accessed using a member of a different
type (C90 6.3.2.3).
The relevant bytes of the representation of the object are treated as an
object of the type used for the access. This may be a trap representation.
---------------------------->8--------------------------------------
Par contre, je n'ai pas vu dans la doc la mention d'un warning ad hoc ?
Toute machine qui se respecte a sa console sur un port serie... :-)
La question n'est pas de savoir si elle a une console sur port série,
Euh, juste une question idiote: comment traduire "This may be a trap
representation" ?
Euh, juste une question idiote: comment traduire "This may be a trap
representation" ?
Euh, juste une question idiote: comment traduire "This may be a trap
representation" ?