buf[0]

наверное что-то типа такого должно быть:

C++ (Qt)
quint16 n = *(reinterpret_cast<quint16 *>(buf));

qFromLittleEndian, qFromBigEndian.

Что за мифическое выравнивание? Давайте проверим

C++ (Qt)
#pragma pack(push, 1)
struct CTest {
 char ch;
 char buf[128];
};
#pragma pack(pop)
...
CTest test;
quint16 * dst = (quint16 *) &test.buf[0];
*dst = 5;
qDebug() << dst << *dst;
 

Неужели *dst не будет правильно читаться/писаться если стоит по нечетному адресу ?  

Давайте так (чуть изменил печать)

C++ (Qt)
#pragma pack(push, 1)
char buf[128] = {0};
#pragma pack(pop)
 
buf[1] = 0x34;
buf[2] = 0x12;
quint16 *dst = (quint16 *) &buf[1];
printf("dst = 0x%x\n", (int) *dst);
*dst = 0xABCD;
printf("dst = 0x%x\n", (int) *dst);
 

Вывод

С чего Вы это взяли Пишется начиная с того адреса который дали. Просто если он не выровнен, процессор затратит больше времени ("штрафные такты" и все такое) - но никакой ошибки мы не словим

А о чем вообще спор? ТС спросил как из байтового массива получить 2-хбайтное? Ему посоветовали
Видать ТС новичок и плохо разбирается в привидении типа.  Он этот код использует у себя.... и возможно его buf[0] выровнен к 4. Или у него процессор 8-ми битный. Он в своем коде ни когда не словит ошибку.  Я предостерёг, что пользуясь таким кодом нужно следить за выравниванием. В чем я не прав? Ни кто ему не сказал сделай так Нужно понимать, что на конкретной архитектуре выравнивание может быть 2 или 4. На некоторых архитектурах не работают прагмы. То, что вы проверили на конкретной архитектуре и заработало - это не значит что будет работать везде. На AVR без прагмы всё будет работать.
ТС использует такое приведение типа без прагмы, как посоветовали, код будет работать. ТС усвоит урок. Потом в другом месте сделает также (или использует этот код)... и обратится по невыровненным данным.... выстрелит себе в ногу. "Прозанимается любовью" с этой багой.... и соскочит на жаву. А потом возникают на форумах холивары, что с/с++ гавно.

Вы в своем коде проследили за выравниванием, т.е. вы прагмами изменили выравнивание к 1. Я говорю тоже самое - нужно учитывать выравнивание.

psя уже говорил, что такой код не дает проверки. если разыменование *dst происходит неправильно, то вы в неправильный адрес запишите 0xABCD, а потом проверяете прочитав также из неправильного адреса.

Если на конкретной архитектуре выравнивание 4, то с подобным приведением типа вы должны позаботиться о выравнивании. либо вы должны чтобы buf был кратен 4, либо вы должны указать прагмой нужное выравнивание. выравнивание 4 - это не мифический процессор. Вот  http://www.moxa.com/product/UC-8410.htm - вполне не мифическая микроЭВМ с немифическим Intel XScale IXP435 533 MHz processor.


Смешно както.... "Что за мифическое выравнивание? Давайте проверим" - и тут же приводите проверочный код, в котором вы позаботились о выравнивании. Если это выравнивание мифическое, зачем вы прагмой изменили выравнивание к 1? Ваш проверочный код выровнен к 1. И данные выровнены к 1. Можно спокойно обращаться к адресам кратным 1. Вы проверьте без выравнивания.

От каких мифических угроз?  На любом процессоре и любой архитектуре, если делаешь привидение типа
проследи, чтобы буф был выровнен. если по дефолту выравнивание 4 - смотри чтоб буф был выровнен к 4. Если ваш буф по нечетному адресу, то измени выравнивание к 1 (хотя не везде это сработает). Так или иначе, но программист обязан следить за выравниванием, при подобном приведении типа. В чем я не прав?

С ваших слов, выравнивание это миф и о нем заботиться не нужно. И в качестве доказательства приводите пример с выровненными данными. В чем смысл?