Почему sockaddr_storage структура определила как способ, которым она определяется?
long time1, time2;
time1 = System.currentMillis();
.. drink coffee
time2 = System.currentMillis();
long difference = time2 - time1 // millies between time1 and time2
java.util.Date differneceDate = new Date(difference);
Для создания строки как "2 Минуты" необходимо использовать DateFormatter/DateFormat. Можно найти больше деталей об этом в спецификация API Java (java.sun.com).
2 ответа
Предложенная вами альтернатива не заставит всю структуру быть выровненной по 8-байтовой (64-битной) границе, что вы указываете как требование из RFC2553.
В общем, структура требует строжайшего выравнивания, требуемого любым из ее членов. Поскольку sa_family_t , вероятно, является u16_t , для которого требуется только 2-байтовое выравнивание, а для массива char требуется выравнивание не более 1 байта, предлагаемая вами альтернатива потребует только 2-байтового выравнивание. (Скорее всего, компилятор все равно предоставит ему как минимум 4-, а может быть и 8-байтовое выравнивание, но вы не можете быть уверены в этом.)
Стиль фактического определения - это попытка убедиться, что каждый байт в структура является частью некоторого именованного поля, т. е. компилятор не вставляет никаких отступов между полями. Это необходимо (вроде) для того, чтобы _SS_PAD2SIZE имел значение, которое можно вычислить в терминах размеров всех других членов.
Однако я считаю это определение довольно сложным. Я почти уверен, что следующее работает так же хорошо, и его немного легче понять:
struct sockaddr_storage {
union {
sa_family_t u_family;
uint64_t u_pad[_SS_MAXSIZE / sizeof(uint64_t)];
} __ss_u;
# define __ss_family __ss_u.u_family
};
Здесь объединение получает требования выравнивания своего наиболее строго выровненного члена, которые затем распространяются на включающую структуру. Обратите внимание, что в этой версии у меня есть только одно обязательное поле (хотя и скрыто в объединении) и один массив заполнения, который является точным размером, который я хочу, чтобы вся структура была. Единственная немного сложная часть - это макроопределение __ ss_family . Возможно, трюк с макросами не совсем соответствует требованиям RFC, но будет несколько (если таковые имеются) способов заметить разницу.
Итак, из того, что вы говорите, кажется, что
a.
int64_t __ss_align;
приводит к выравниванию структуры по 64-битной границе.
б. __ ss_pad1 гарантирует, что ss_family находится на 64-битной границе непосредственно перед __ss_align
c. __ ss_pad2 обеспечивает требуемый общий размер.
Я прочитал приведенный выше код на http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/socket.h.html#tag_13_61 . Из того, что там написано, кажется, что значение _SS_MAXSIZE должно определяться разработчиком.
В коде, упомянутом Дейлом, разделение в
uint64_t u_pad [_SS_MAXSIZE / sizeof (uint64_t)]
вызовет значение с плавающей запятой, которое затем будет усечено, в результате чего структура будет меньше, чем требуемый размер (_SS_MAXSIZE).
:)