forcer un cast

Bismark Prods wrote:

Bonjour,

Bonjour,

Je reprend un code écrit en C et il y a là un cast qui bug à chaque fois !
Comment peut-on faire pour forcer coute que coute un cast ?
J'ai essayé static_cast<> et (type)valeur

ce sont les seuls moyens de faire un cast, le (type) valeur force déjà le
cast (et est équivalent à un reinterpret_cast<>()) et le static_cast<>()
permet un certain contrôle à la compilation vu qu'il fait des conversions
entre types de même "famille". (alors que (type) valeur et
reinterpret_cast<>() réinterprètes juste les bits du type de données pour
en faire une donnée de l'autre type)
Il reste un dernier type de "cast" qui sont les opérateurs de conversion.
Lorsque l'on veut convertir un double en int par exemple on peut utiliser la
notation constructeur :

double d = 42.0;
int i = int(d);

Mais rien n'y fait !

Quel est le code incriminé ? si il y a vraiment un bug, c'est que ca ne
vient pas spécialement du cast, enfin c'est que cette opération tentée
n'est *vraiment* pas autorisée.

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

Bismark Prods wrote:

Bonjour,

Je reprend un code écrit en C et il y a là un cast qui bug à chaque
fois !
Ca veut dire quoi "qui bug"? A chaque fois qu'on n'obtient pas le

comportement souhaité avec un code copieusement parsemé de casts, c'est
99.99% des cas parce que un cast est faux : Le compilateur est généralement
assez malin pour nous prévenir des erreurs de conversion et vouloir lui
"forcer la main" avec des casts est presque toujours une mauvaise idée.

Comment peut-on faire pour forcer coute que coute un cast ?
reiunterpret_cast, mais je suis quasi-certain que ton programme plantera

avec çà. Pour être sûr, bien entendu, il faudrait voir le code...

Arnaud

Merci de me répondre, voici ce que le programme en C faisait que celui en
C++ refuse de faire :

Il y a la structure : inflate_state suivante :

/* state maintained between inflate() calls. Approximately 7K bytes. */
struct inflate_state {
inflate_mode mode; /* current inflate mode */
int last; /* true if processing last block */
int wrap; /* bit 0 true for zlib, bit 1 true for gzip
*/
int havedict; /* true if dictionary provided */
int flags; /* gzip header method and flags (0 if zlib)
*/
unsigned long check; /* protected copy of check value */
unsigned long total; /* protected copy of output count */
/* sliding window */
unsigned wbits; /* log base 2 of requested window size */
unsigned wsize; /* window size or zero if not using window
*/
unsigned whave; /* valid bytes in the window */
unsigned write; /* window write index */
unsigned char FAR *window; /* allocated sliding window, if needed */
/* bit accumulator */
unsigned long hold; /* input bit accumulator */
unsigned bits; /* number of bits in "in" */
/* for string and stored block copying */
unsigned length; /* literal or length of data to copy */
unsigned offset; /* distance back to copy string from */
/* for table and code decoding */
unsigned extra; /* extra bits needed */
/* fixed and dynamic code tables */
code const FAR *lencode; /* starting table for length/literal codes
*/
code const FAR *distcode; /* starting table for distance codes */
unsigned lenbits; /* index bits for lencode */
unsigned distbits; /* index bits for distcode */
/* dynamic table building */
unsigned ncode; /* number of code length code lengths */
unsigned nlen; /* number of length code lengths */
unsigned ndist; /* number of distance code lengths */
unsigned have; /* number of code lengths in lens[] */
code FAR *next; /* next available space in codes[] */
unsigned short lens[320]; /* temporary storage for code lengths */
unsigned short work[288]; /* work area for code table building */
code codes[ENOUGH]; /* space for code tables */
};

Et il y a la structure internal_state suivante :

/* A Pos is an index in the character window. We use short instead of int to
* save space in the various tables. IPos is used only for parameter
passing.
*/

typedef struct internal_state {
z_streamp strm; /* pointer back to this zlib stream */
int status; /* as the name implies */
Bytef *pending_buf; /* output still pending */
ulg pending_buf_size; /* size of pending_buf */
Bytef *pending_out; /* next pending byte to output to the stream */
int pending; /* nb of bytes in the pending buffer */
int wrap; /* bit 0 true for zlib, bit 1 true for gzip */
Byte data_type; /* UNKNOWN, BINARY or ASCII */
Byte method; /* STORED (for zip only) or DEFLATED */
int last_flush; /* value of flush param for previous deflate call
*/

/* used by deflate.c: */

uInt w_size; /* LZ77 window size (32K by default) */
uInt w_bits; /* log2(w_size) (8..16) */
uInt w_mask; /* w_size - 1 */

Bytef *window;
/* Sliding window. Input bytes are read into the second half of the
window,
* and move to the first half later to keep a dictionary of at least
wSize
* bytes. With this organization, matches are limited to a distance of
* wSize-MAX_MATCH bytes, but this ensures that IO is always
* performed with a length multiple of the block size. Also, it limits
* the window size to 64K, which is quite useful on MSDOS.
* To do: use the user input buffer as sliding window.
*/

ulg window_size;
/* Actual size of window: 2*wSize, except when the user input buffer
* is directly used as sliding window.
*/

Posf *prev;
/* Link to older string with same hash index. To limit the size of this
* array to 64K, this link is maintained only for the last 32K strings.
* An index in this array is thus a window index modulo 32K.
*/

Posf *head; /* Heads of the hash chains or NIL. */

uInt ins_h; /* hash index of string to be inserted */
uInt hash_size; /* number of elements in hash table */
uInt hash_bits; /* log2(hash_size) */
uInt hash_mask; /* hash_size-1 */

uInt hash_shift;
/* Number of bits by which ins_h must be shifted at each input
* step. It must be such that after MIN_MATCH steps, the oldest
* byte no longer takes part in the hash key, that is:
* hash_shift * MIN_MATCH >= hash_bits
*/

long block_start;
/* Window position at the beginning of the current output block. Gets
* negative when the window is moved backwards.
*/

uInt match_length; /* length of best match */
IPos prev_match; /* previous match */
int match_available; /* set if previous match exists */
uInt strstart; /* start of string to insert */
uInt match_start; /* start of matching string */
uInt lookahead; /* number of valid bytes ahead in window */

uInt prev_length;
/* Length of the best match at previous step. Matches not greater than
this
* are discarded. This is used in the lazy match evaluation.
*/

uInt max_chain_length;
/* To speed up deflation, hash chains are never searched beyond this
* length. A higher limit improves compression ratio but degrades the
* speed.
*/

uInt max_lazy_match;
/* Attempt to find a better match only when the current match is
strictly
* smaller than this value. This mechanism is used only for compression
* levels >= 4.
*/
# define max_insert_length max_lazy_match
/* Insert new strings in the hash table only if the match length is not
* greater than this length. This saves time but degrades compression.
* max_insert_length is used only for compression levels <= 3.
*/

int level; /* compression level (1..9) */
int strategy; /* favor or force Huffman coding*/

uInt good_match;
/* Use a faster search when the previous match is longer than this */

int nice_match; /* Stop searching when current match exceeds this */

/* used by trees.c: */
/* Didn't use ct_data typedef below to supress compiler warning */
struct ct_data_s dyn_ltree[HEAP_SIZE]; /* literal and length tree */
struct ct_data_s dyn_dtree[2*D_CODES+1]; /* distance tree */
struct ct_data_s bl_tree[2*BL_CODES+1]; /* Huffman tree for bit lengths
*/

struct tree_desc_s l_desc; /* desc. for literal tree */
struct tree_desc_s d_desc; /* desc. for distance tree */
struct tree_desc_s bl_desc; /* desc. for bit length tree */

ush bl_count[MAX_BITS+1];
/* number of codes at each bit length for an optimal tree */

int heap[2*L_CODES+1]; /* heap used to build the Huffman trees */
int heap_len; /* number of elements in the heap */
int heap_max; /* element of largest frequency */
/* The sons of heap[n] are heap[2*n] and heap[2*n+1]. heap[0] is not
used.
* The same heap array is used to build all trees.
*/

uch depth[2*L_CODES+1];
/* Depth of each subtree used as tie breaker for trees of equal
frequency
*/

uchf *l_buf; /* buffer for literals or lengths */

uInt lit_bufsize;
/* Size of match buffer for literals/lengths. There are 4 reasons for
* limiting lit_bufsize to 64K:
* - frequencies can be kept in 16 bit counters
* - if compression is not successful for the first block, all input
* data is still in the window so we can still emit a stored block
even
* when input comes from standard input. (This can also be done for
* all blocks if lit_bufsize is not greater than 32K.)
* - if compression is not successful for a file smaller than 64K, we
can
* even emit a stored file instead of a stored block (saving 5
bytes).
* This is applicable only for zip (not gzip or zlib).
* - creating new Huffman trees less frequently may not provide fast
* adaptation to changes in the input data statistics. (Take for
* example a binary file with poorly compressible code followed by
* a highly compressible string table.) Smaller buffer sizes give
* fast adaptation but have of course the overhead of transmitting
* trees more frequently.
* - I can't count above 4
*/

uInt last_lit; /* running index in l_buf */

ushf *d_buf;
/* Buffer for distances. To simplify the code, d_buf and l_buf have
* the same number of elements. To use different lengths, an extra flag
* array would be necessary.
*/

ulg opt_len; /* bit length of current block with optimal trees */
ulg static_len; /* bit length of current block with static trees */
uInt matches; /* number of string matches in current block */
int last_eob_len; /* bit length of EOB code for last block */

#ifdef DEBUG
ulg compressed_len; /* total bit length of compressed file mod 2^32 */
ulg bits_sent; /* bit length of compressed data sent mod 2^32 */
#endif

ush bi_buf;
/* Output buffer. bits are inserted starting at the bottom (least
* significant bits).
*/
int bi_valid;
/* Number of valid bits in bi_buf. All bits above the last valid bit
* are always zero.
*/

} FAR deflate_state;

Or donc le programme C arrivait à affecter la structure inflate_state dans
la structure internal_state (internal_state est bien plus importante en
terme de taille que inflate_state, donc il ne peut pas y avoir dépassement).

Si vous avez une solution ca serait vraiment formidable.

Merci

Bismark

"Anthony Fleury" <fleury_anthony@_hotmail_.com> a écrit dans le message de
news:40b9e7cc$0$7708$636a15ce@news.free.fr...

Bismark Prods wrote:

Bonjour,

Bonjour,

Je reprend un code écrit en C et il y a là un cast qui bug à chaque fois
!

Comment peut-on faire pour forcer coute que coute un cast ?
J'ai essayé static_cast<> et (type)valeur

ce sont les seuls moyens de faire un cast, le (type) valeur force déjà le
cast (et est équivalent à un reinterpret_cast<>()) et le static_cast<>()
permet un certain contrôle à la compilation vu qu'il fait des conversions
entre types de même "famille". (alors que (type) valeur et
reinterpret_cast<>() réinterprètes juste les bits du type de données pour
en faire une donnée de l'autre type)
Il reste un dernier type de "cast" qui sont les opérateurs de conversion.
Lorsque l'on veut convertir un double en int par exemple on peut utiliser
la

notation constructeur :

double d = 42.0;
int i = int(d);

Mais rien n'y fait !

Quel est le code incriminé ? si il y a vraiment un bug, c'est que ca ne
vient pas spécialement du cast, enfin c'est que cette opération tentée
n'est *vraiment* pas autorisée.

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

Bismark Prods wrote:

Merci de me répondre, voici ce que le programme en C faisait que celui en
C++ refuse de faire :

Il y a la structure : inflate_state suivante :

[ snip les grosses structures ]

Au passage les typedefs sont inutils en C++ pour des structures.

Or donc le programme C arrivait à affecter la structure inflate_state dans
la structure internal_state (internal_state est bien plus importante en
terme de taille que inflate_state, donc il ne peut pas y avoir
dépassement).

Si vous avez une solution ca serait vraiment formidable.

Si c'est seulement une affectation, pourquoi ne pas utiliser std::memcpy
dans <cstring> ? comme on pourrait le faire en C en fait.

en fait sur ce point je ne vois pas la différence qui pourrait exister entre
le programme C et le programme C++ et un reinterpret_cast<> () aurait le
même comportement qu'un cast à la C, et le cast à la C aurait le
comportement qu'il a en C...

je pense donc à un comportement indéfini plutot, du genre, y a t il
tentative d'accès à l'un des membres de la structure ainsi castée et
affectation ensuite ? ou déréférencement de l'un des pointeurs qui du fait
des bits de padding n'aurait pas du tout la valeur attendue ?
En clair je pense plutot à un problème du programme C de départ que d'un
problème de cast en C++.

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

Une chose que je n'ai pas mentionné est que le cast tente en réalité un
casting sur fonction (sur pointeur).

Mais votre réponse me satisfait pleinement. Je pense que je vais pouvoir y
remedier.

Merci

Bismark

"Anthony Fleury" <fleury_anthony@_hotmail_.com> a écrit dans le message de
news:40ba47fc$0$12752$636a15ce@news.free.fr...

Bismark Prods wrote:

Merci de me répondre, voici ce que le programme en C faisait que celui
en

C++ refuse de faire :

Il y a la structure : inflate_state suivante :

[ snip les grosses structures ]

Au passage les typedefs sont inutils en C++ pour des structures.

Or donc le programme C arrivait à affecter la structure inflate_state
dans

la structure internal_state (internal_state est bien plus importante en
terme de taille que inflate_state, donc il ne peut pas y avoir
dépassement).

Si vous avez une solution ca serait vraiment formidable.

Si c'est seulement une affectation, pourquoi ne pas utiliser std::memcpy
dans <cstring> ? comme on pourrait le faire en C en fait.

en fait sur ce point je ne vois pas la différence qui pourrait exister
entre

le programme C et le programme C++ et un reinterpret_cast<> () aurait le
même comportement qu'un cast à la C, et le cast à la C aurait le
comportement qu'il a en C...

je pense donc à un comportement indéfini plutot, du genre, y a t il
tentative d'accès à l'un des membres de la structure ainsi castée et
affectation ensuite ? ou déréférencement de l'un des pointeurs qui du fait
des bits de padding n'aurait pas du tout la valeur attendue ?
En clair je pense plutot à un problème du programme C de départ que d'un
problème de cast en C++.

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

Bismark Prods wrote:

[ il est plus lisible de répondre après le message auquel on répond, de
manière à respecter la logique de lecture ]

Une chose que je n'ai pas mentionné est que le cast tente en réalité un
casting sur fonction (sur pointeur).

Mais votre réponse me satisfait pleinement. Je pense que je vais pouvoir y
remedier.

Merci

Bismark

Je n'ai pas vraiment compris ce que venait faire les pointeurs de fonctions
ici et doit avouer que je suis un peu perdu sans code minimal representant
le problème. (et même sans code tout court, nous n'avons eu que les
définitions de deux structures) En fait, tout du moins pour moi, je ne peux
faire avec les informations données que des suppositions et donc dire que
si ca fonctionnait avec un cast à la C en C et que ca fonctionne pas avec
un cast à la C en C++ c'est un comportement indéfini dans le code C. Mais
je précise bien que ce ne sont que des suppositions.

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

"Anthony Fleury" <fleury_anthony@_hotmail_.com> a écrit dans le message de
news:40ba5689$0$12755$636a15ce@news.free.fr...

Bismark Prods wrote:

[ il est plus lisible de répondre après le message auquel on répond, de
manière à respecter la logique de lecture ]

Une chose que je n'ai pas mentionné est que le cast tente en réalité un
casting sur fonction (sur pointeur).

Mais votre réponse me satisfait pleinement. Je pense que je vais pouvoir
y

remedier.

Merci

Bismark

Je n'ai pas vraiment compris ce que venait faire les pointeurs de
fonctions

ici et doit avouer que je suis un peu perdu sans code minimal representant
le problème. (et même sans code tout court, nous n'avons eu que les
définitions de deux structures) En fait, tout du moins pour moi, je ne
peux

faire avec les informations données que des suppositions et donc dire que
si ca fonctionnait avec un cast à la C en C et que ca fonctionne pas avec
un cast à la C en C++ c'est un comportement indéfini dans le code C. Mais
je précise bien que ce ne sont que des suppositions.

Merci vos explications me suffisent ! Désolé je ne sais pas très bien
répondre après les messages précédents. Pas habitués à ce mode de réponse.

Merci encore et bonne continuation.

Bismark

Anthony
--
It's a bird.. It's a plane..
No, it's KernelMan, faster than a speeding bullet, to your rescue.
Doing new kernel versions in under 5 seconds flat..
-- Linus, in the announcement for 1.3.27

"Anthony Fleury" <fleury_anthony@_hotmail_.com> a écrit dans le message de
news:40b9e7cc$0$7708$636a15ce@news.free.fr...

Bismark Prods wrote:

Bonjour,

Bonjour,

Je reprend un code écrit en C et il y a là un cast qui bug à chaque fois
!

Comment peut-on faire pour forcer coute que coute un cast ?
J'ai essayé static_cast<> et (type)valeur

ce sont les seuls moyens de faire un cast, le (type) valeur force déjà le
cast (et est équivalent à un reinterpret_cast<>())

Bonjour,

Ce n'est pas tout à fait exact, le cast (type) est interprété par le
compilateur en fonction de ce qu'il connaît déjà des types des variables.

Il peut aller de const_cast<>() à reinterpret_cast<>() en passant par
static_cast<>() et certaines combinaisons de const_cast avec static_cast...

Des spécialistes pourront donner la liste de mémoire ;-)

L'idée est que le compilateur choisira le cast le "moins violent" pour
obtenir le résultat souhaité.

Par exemple, le compilateur HP émet un warning lorsqu'il ne peut faire qu'un
reinterpret_cast<>() pour traduire un cast C.

Rémy