[HS] gcc et warning sur flexible array member

Bon, juste une question HS: j'ai cherché sans trouver une
option de gcc pour détecter les flexible array member,
sans succès.

J'ai mal cherché ou il n'y en a pas ?

C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};

Comme c'est du C99 : -ansi -pedantic

--
Richard

Richard Delorme wrote:

C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};

Comme c'est du C99 : -ansi -pedantic

Oui, mais j'ai oublié de dire que j'aimerais rester en C99 :-(
C'est C99 qui ajoute <stdbool.h>, non ? Puis en 2005, enseigner
C89, j'aurais l'impression de tricher un peu.

Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.

Marc Boyer wrote:

Bon, juste une question HS: j'ai cherché sans trouver une
option de gcc pour détecter les flexible array member,
sans succès.

J'ai mal cherché ou il n'y en a pas ?

C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};

Une fois que leur code compile sans warning en C99:

gcc -stdÈ9 -pedantic -fpermissive code.c | grep "flexible array"

Jamais teste ;-)

a+, ld.

Marc Boyer wrote:

Richard Delorme wrote:

C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};

Comme c'est du C99 : -ansi -pedantic

Oui, mais j'ai oublié de dire que j'aimerais rester en C99 :-(
C'est C99 qui ajoute <stdbool.h>, non ?

Tu leurs fais ajouter ton header apres les headers standards, ca marche
en C89, C99 et tous les modes etendus de gcc.

a+, ld.

#ifndef MARC_BOYER_H
#define MARC_BOYER_H

# if !__bool_true_false_are_defined
#define __bool_true_false_are_defined 1
# ifndef bool
typedef unsigned char bool;
# define bool bool
# endif
# ifndef false
# define false 0
# endif
# ifndef true
# define true 1
# endif
# endif

#endif

Richard Delorme wrote:

C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};

Comme c'est du C99 : -ansi -pedantic

Oui, mais j'ai oublié de dire que j'aimerais rester en C99 :-(
C'est C99 qui ajoute <stdbool.h>, non ? Puis en 2005, enseigner
C89, j'aurais l'impression de tricher un peu.

Je ne pense pas. Ce qui est défini par C89 est encore valable pour
beaucoup de choses. D'autre part, si tes élèves sont complètement
débutants, leur faire assimiler les VLA serait prématuré, mieux vaut
leur faire assimiler des choses comme la priorité des opérateurs du
langage C ou les pointeurs. Ils découvraient par eux-même les VLA
ainsi que les autres joyeusetés de C99.

Regis

Targeur fou wrote:

Richard Delorme wrote:

C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};

Comme c'est du C99 : -ansi -pedantic

Oui, mais j'ai oublié de dire que j'aimerais rester en C99 :-(
C'est C99 qui ajoute <stdbool.h>, non ? Puis en 2005, enseigner
C89, j'aurais l'impression de tricher un peu.

Je ne pense pas. Ce qui est défini par C89 est encore valable pour
beaucoup de choses. D'autre part, si tes élèves sont complètement
débutants, leur faire assimiler les VLA serait prématuré, mieux vaut
leur faire assimiler des choses comme la priorité des opérateurs du
langage C ou les pointeurs. Ils découvraient par eux-même les VLA
ainsi que les autres joyeusetés de C99.

Ben oui, dans mon cours, j'ai pas parlé des VLA. Mais là, je
corrige mes copies, et j'en ai plein qui utilise des VLA en
croyant utiliser un pointeur. Et le compilo a rien dit, puisque
c'est du C99.
Reste l'option C89 + #include <boyerbool.h>

typedef enum {true=1, false=0} bool;


Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.

Je ne pense pas. Ce qui est défini par C89 est encore valable pour
beaucoup de choses. D'autre part, si tes élèves sont complètement
débutants, leur faire assimiler les VLA serait prématuré, mieux vaut
leur faire assimiler des choses comme la priorité des opérateurs du
langage C ou les pointeurs. Ils découvraient par eux-même les VLA
ainsi que les autres joyeusetés de C99.

Ben oui, dans mon cours, j'ai pas parlé des VLA. Mais là, je
corrige mes copies, et j'en ai plein qui utilise des VLA en
croyant utiliser un pointeur. Et le compilo a rien dit, puisque
c'est du C99.
Reste l'option C89 + #include <boyerbool.h>

typedef enum {true=1, false=0} bool;
Honnêtement, si ce n'est pas en cours qu'on apprend le C99, comment

espérez-vous répandre son utilisation ?

Sans forcément faire un cours sur les VLA, mentionner leur existence, à
quoi ils servent, etc. serait bénéfique. Par exemple, vous donnez les
bases nécessaires au cours de programmation, et lorsque celles-ci
(tableaux, pointeurs, passage par valeur, et tutti quanti) sont assimilés,
consacrer un cours aux spécificités que vous n'avez pas (eu) le temps
d'aborder me semble utile.

Dans mes cours de C, à l'époque, nous avons découvert l'utilisation
d'opérateurs "raccourcis" (+=, ++, test?a:b ,etc.) relativement tard dans
le cursus.

(le fait que certains sachent déjà qu'ils existaient n'était pas un
problème, mais ils n'étaient pas encouragés à trop en parler de peur de
trop installer de confusion)

Ils sont utiles pour programmer, mais ne sont pas indispensables. Un peu
comme les VLA... :-)

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

[...]

Dans mes cours de C, à l'époque, nous avons découvert l'utilisation
d'opérateurs "raccourcis" (+=, ++, test?a:b ,etc.) relativement tard dans
le cursus.
[...]

Ils sont utiles pour programmer, mais ne sont pas indispensables. Un peu
comme les VLA... :-)
(je ne m'oppose pas à ce qui est écrit, j'en profite pour aborder un

point qui me titille)
La différence entre les opérateurs raccoucis et les VLAs, c'est que les
premiers sont de toutes les versions de C (et C++) et qu'ils ont des
structures équivalentes faciles à remplacer, alors que pour les VLAs,
c'est très loin d'être le cas.
*Je me mets dans un cadre resreint, celui des machines achetées au
supermarché et de compilateurs courants sur ces machines*. En fait, le
champs de mes remarques pourrait certainement être élargi.
Faisons le point: pas supportés chez Borland (oublions 6.0, le "futur
C99", qui restera sans doute futur). Pas supporté chez Microsoft.
Supporté avec restrictions chez le gnou:
http://gcc.gnu.org/gcc-4.0/c99status.html
<extrait>
The C99 semantics of variable length arrays (VLAs) are not fully
implemented by the existing GCC extension: the concept of variably
modified (VM) types, and the rules for what identifiers can be declared
with VLA or VM types, are not implemented (for example, GCC allows
elements of VM type in a structure with block scope); while the syntax
for arrays to be declared with [*] in parameter declarations is
present, the semantics are not; and in general the implementation of
VLAs has not been checked against C99 requirements.
</extrait>
Pour cette raison, je n'ai pas pu tester les VLAs, mais il me semble
que leur utilisation touche à la conception même du code de façon
relativement profonde, donc un retour en arrière (vers C89) non
mécanique.
Je me pose donc la question de l'utilité d'une portabilité C99 stricte,
avec VLAs. On va être portable, mais non compatible avec beaucoup de
compilateurs, qui sont souvent incontournables dans certains contextes.
Franchement, je préfère une conformité C89 à une "portabilité Comeau".
Et je ne crache pas sur une compilabilité C++98 (Damned, Satan m'habite
:D ), quitte à caster les retours de malloc().
En revanche, je ne sais trop que penser des facilités issues de C++,
présentes dans C99 et souvent admises en C(avec le bon commutateur, ou
en incluant le bon header). Je pense par exemple aux commentaires fin
de ligne //, aux bool, aux déclaration au sein du bloc.

--
Pierre

Pierre Maurette wrote:

En revanche, je ne sais trop que penser des facilités issues de C++,
présentes dans C99 et souvent admises en C(avec le bon commutateur, ou
en incluant le bon header). Je pense par exemple aux commentaires fin
de ligne //, aux bool, aux déclaration au sein du bloc.

// c'est très bien. Cela incite à mettre des commentaires.
Et un compilo qui n'est pas capable d'implémenter ça pour le lendemain
ne vaut pas la peine qu'on s'y attarde.

Je ne savais pas que l'on pouvais faire des déclarations au sein d'un
bloc, faudra que j'essaye, il est possible que je me demande ensuite
comment j'ai pu m'en passer, mais a priori en C ça a surtout un interet
théorique.
Je pense qu'il y aurait eu des choses plus importantes à mettre dans la
norme.

bool (ravi de faire sa connaissance) ça doit être bien, mais je m'en
passe encore.

Les "tableaux flexibles", je m'en suis déjà servi sous gcc, ça marche
(au moins pour une utilisation triviale mais je n'ai pas poussé le
compilo dans ses retranchements). C'est en tout cas très utile.

--
Patrick.
http://patrick.davalan.free.fr/

Marc Boyer wrote:

Targeur fou wrote:

Richard Delorme wrote:

C'est pour mes pauv' étudiants qui écrivent
struct Vecteur {
size_t size;
double val[];
};
en lieu et place de
struct Vecteur {
size_t size;
double *val;
};

Comme c'est du C99 : -ansi -pedantic

Oui, mais j'ai oublié de dire que j'aimerais rester en C99 :-(
C'est C99 qui ajoute <stdbool.h>, non ? Puis en 2005, enseigner
C89, j'aurais l'impression de tricher un peu.

Je ne pense pas. Ce qui est défini par C89 est encore valable pour
beaucoup de choses. D'autre part, si tes élèves sont complètement
débutants, leur faire assimiler les VLA serait prématuré, mieux vaut
leur faire assimiler des choses comme la priorité des opérateurs du
langage C ou les pointeurs. Ils découvraient par eux-même les VLA
ainsi que les autres joyeusetés de C99.

Ben oui, dans mon cours, j'ai pas parlé des VLA. Mais là, je
corrige mes copies, et j'en ai plein qui utilise des VLA en
croyant utiliser un pointeur. Et le compilo a rien dit, puisque
c'est du C99.

Tu parles de VLA ou de flexible array. C'est deux choses differentes.
Ton exemple parle bien de flexible array (note pour les reponses des
posts suivants) qui sont supportes par la pluspart des compilos pre-C99.
Pour les VLA c'est autre chose.

Reste l'option C89 + #include <boyerbool.h>

typedef enum {true=1, false=0} bool;

Definition incompatible avec c99...

6.3.1.1
-- The rank of long long int shall be greater than the rank of long int,
which shall be greater than the rank of int, which shall be greater than
the rank of short int, which shall be greater than the rank of signed char.
-- The rank of _Bool shall be less than the rank of all other standard
integer types.

Un enum est de type int. int a un rank plus grand que char et short.
Donc au mieux, mais toujours pas correct, tu peux definir _Bool (ou
bool) comme un unsigned char. Ceci dit, c'est aussi incompatible avec
c99 puisque:

6.7.2.1-4
A bit-field shall have a type that is a qualified or unqualified version
of _Bool, signed int, unsigned int, or some other implementation-defined
type.

Fait ton choix d'incompatibilite camarade ;-). Moi j'ai choisi d'etre
compatible avec le rank parce que je prohibe les bit-field et qu'un
tableau de bool est plus petit si c'est un unsigned char.

Dernier point, pour convertir un integral type en bool, il faut faire
!!value (on dirait du Eiffel ;-) )

a+, ld.