2016-08-19 7 views
0

У меня проблема с псевдонимом. Я никогда не сталкивался с этим раньше. Я использую Eclipse CDT. Я читал разные решения, но я не мог найти подходящий для меня.предупреждение! разыменованный тип-караульный указатель нарушит правила строгого сглаживания [-Wstrict-aliasing]

У меня есть предупреждение,

разыменования указателя типа-каламбурил будет нарушать правила строгого сглаживания [-Wstrict-алиасов]

Так у меня есть следующий мир кода:

timestamp = st0 % 100000000; 

for (std::list<struct trace *>::iterator it = frame_list.begin(); 
    it != frame_list.end(); 
    ++it) { 
    struct my_rtppacket *packet = NULL; 
    packet = new struct my_rtppacket; 

    packet->ts = (int32_t)((*it)->time * 1000000); 
    packet->seq = count_seq; 

    //In the following two strings I have the warnings :(

    *(uint16_t*) (packet->buf + 2) = htons(packet->seq); 
    *(int32_t*) (packet->buf + 4) = htonl(packet->ts + timestamp); 

    insert_data_to_list(packet); // This function inserts packets to list} 
} 

В результате возникают неправильные значения в packet->buf + 2 и packet->buf + 4.

Пожалуйста, примите во внимание! Помогите мне решить эту проблему!

EDIT Я хочу, чтобы понять, что случилось ... Структура my_rtppacket определяется следующим образом:

{ 
struct my_rtppacket 
{ 
public: 
    my_rtppacket():dump_ts(0), payloadlen(0),packetlen(0),ts(0), seq(0), seq_fr(0), frame_number(0), 
    erase(NUM, INIT), path(NUM, INIT), create_time(0), alloc_time(0), before_create(0), sent_flag(0){} 
    uint32_t dump_ts; /*timestamp of RTP dump. It is similar to timestamp of packet generation from the application*/ 
    int payloadlen; 
    int packetlen; 
    int32_t ts;   /*timestamp in RTP file*/ 
    uint16_t seq;  /* Sequеnce number in video sequence*/ 
    int seq_fr;   /* Sequеnce number in a frame*/ 
    int frame_number; 
    char buf[1600]; 
    std::vector <path_t> erase; 
    std::vector <path_t> path;  //Declare a vector of path_type elements 
    char frame_type[10]; 
    int64_t create_time; 
    int64_t alloc_time; 
    int64_t before_create; 
    int sent_flag; 

}; 

} 
+3

Эта арифметика указателей, реинтерпретация-отливки и т. Д., Безусловно, выглядит теневым. Однако вам нужно предоставить нам определение «struct my_rptpacket», чтобы быть уверенным. –

+0

Интересно, будет ли упакованная структура (или 2 для endianess) лучше. Или, возможно, создать функцию для заполнения буфера из данных struct ... –

+0

Кстати, как вы думаете, что значения неправильные? –

ответ

1

Вы должны использовать что-то вроде следующего, чтобы не нарушать строгое правило наложения спектров:

const uint16_t nseq = htons(packet->seq); 
const uint32_t nts = htonl(packet->ts + timestamp); 
memcpy(packet->buf + 2, &nseq, 2); 
memcpy(packet->buf + 4, &nts, 4); 
+0

Это решение в порядке, однако можно ли проверить, что было записано в пакет-> buf + 2? –

+0

@EkaterinaPakulova Если вы все еще хотите протестировать свой способ записи в 'packet-> buf', используйте предлагаемый подход для чтения и проверки:' memcpy (& nseq_test_var, packet-> buf + 2, 2); ' –