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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
risc-v: 0.369
KVM: 0.364
user-level: 0.357
permissions: 0.352
graphic: 0.340
performance: 0.337
semantic: 0.332
TCG: 0.324
hypervisor: 0.322
PID: 0.318
network: 0.315
register: 0.305
debug: 0.304
virtual: 0.294
assembly: 0.293
VMM: 0.290
ppc: 0.288
arm: 0.281
device: 0.274
peripherals: 0.271
vnc: 0.270
i386: 0.270
architecture: 0.266
boot: 0.261
kernel: 0.251
files: 0.241
socket: 0.216
mistranslation: 0.215
x86: 0.214
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.
|