1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
KVM: 0.364
other: 0.349
graphic: 0.340
semantic: 0.332
network: 0.315
instruction: 0.297
assembly: 0.293
device: 0.274
vnc: 0.270
boot: 0.261
socket: 0.216
mistranslation: 0.215
TIME_MAX not set correctly for OpenBSD in qemu-common.h
Looking at the OpenBSD buildbot logs I noticed a warning that appears to be a bug in the code.
OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and 64-bit).
CC i386-softmmu/monitor.o
/buildbot-qemu/default_openbsd_current/build/monitor.c: In function 'expire_password':
/buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning: overflow in implicit constant conversion
qemu-common.h has...
#ifndef TIME_MAX
#define TIME_MAX LONG_MAX
#endif
for OpenBSD this should be INT_MAX.
On 11/12/11 5:53 AM, Stefan Weil wrote:
> Am 11.12.2011 07:47, schrieb Brad Smith:
>> Public bug reported:
>>
>> Looking at the OpenBSD buildbot logs I noticed a warning that appears
>> to be a bug in the code.
>> OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and
>> 64-bit).
>>
>> CC i386-softmmu/monitor.o
>> /buildbot-qemu/default_openbsd_current/build/monitor.c: In function
>> 'expire_password':
>> /buildbot-qemu/default_openbsd_current/build/monitor.c:944: warning:
>> overflow in implicit constant conversion
>>
>> qemu-common.h has...
>>
>> #ifndef TIME_MAX
>> #define TIME_MAX LONG_MAX
>> #endif
>>
>> for OpenBSD this should be INT_MAX.
>>
>> ** Affects: qemu
>> Importance: Undecided
>> Status: New
>
> This needs special handling for w32 / w64, too.
> Looking at the code where TIME_MAX is used, I assume that
> more fixes are needed. The following code for example
> won't work:
>
> if (lifetime > INT_MAX) {
>
> What about using
>
> #define TIME_FOREVER -1
>
> instead of TIME_MAX? Of course this would need additional
> code changes.
>
> Regards,
> Stefan Weil
Gerd?
Still looking for comment on this since you added the initial code which
has this bug in it.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Hi,
>>> Looking at the OpenBSD buildbot logs I noticed a warning that appears
>>> to be a bug in the code.
>>> OpenBSD has a 32-bit time_t on all archs at the moment (32-bit and
>>> 64-bit).
Ouch. Adding 64bit arch with 32bit time_t is pretty lame IMHO. There
are a bunch of years left to fix that that though.
>>> #ifndef TIME_MAX
>>> #define TIME_MAX LONG_MAX
>>> #endif
>>>
>>> for OpenBSD this should be INT_MAX.
Guess we'll need an #ifdef then.
>> This needs special handling for w32 / w64, too.
>> Looking at the code where TIME_MAX is used, I assume that
>> more fixes are needed. The following code for example
>> won't work:
>>
>> if (lifetime > INT_MAX) {
With 32bit time_t lifetime wouldn't become larger than INT_MAX anyway,
so it doesn't matter ;)
> Still looking for comment on this since you added the initial code which
> has this bug in it.
cheers,
Gerd
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
Since this bug report was filed OpenBSD has switched from 32-bit time_t to 64-bit time_t on all archs (yes, including 32-bit archs like i386, arm, powerpc). So instead of INT_MAX TIME_MAX should now be set to LLONG_MAX.
This was fixed in commit e7b47c22e2df14d, which was in the 2.11.0 release.
|