summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/105/semantic/1798780
blob: cb4fb496e9040c466d8ba669b8221f36d43a1e54 (plain) (blame)
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
semantic: 0.468
graphic: 0.416
vnc: 0.381
other: 0.366
instruction: 0.348
KVM: 0.329
device: 0.322
assembly: 0.309
boot: 0.301
network: 0.278
socket: 0.268
mistranslation: 0.227

hw/usb/dev-mtp.c:1616: bad test ?

hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively exhaustive tests is always true [-Wlogical-op]

Source code is

                if ((ret == -1) && (errno != EINTR || errno != EAGAIN ||
                                    errno != EWOULDBLOCK)) {

Maybe better code

                if ((ret == -1) && (errno != EINTR && errno != EAGAIN &&
                                    errno != EWOULDBLOCK)) {

On Fri, 19 Oct 2018 at 10:22, dcb <email address hidden> wrote:
> hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively
> exhaustive tests is always true [-Wlogical-op]
>
> Source code is
>
>                 if ((ret == -1) && (errno != EINTR || errno != EAGAIN ||
>                                     errno != EWOULDBLOCK)) {
>
> Maybe better code
>
>                 if ((ret == -1) && (errno != EINTR && errno != EAGAIN &&
>                                     errno != EWOULDBLOCK)) {

Hi Gerd, Bandan -- I was going through older launchpad bugs and
noticed that this one about a dubious conditional in dev-mtp.c is
still unfixed.

Is the file descriptor being used here one that's in non-blocking
mode? If so, then busy-waiting in a loop while the write() returns
EWOULDBLOCK is probably not what you wanted. If it's not then
there's no need to check for EAGAIN or EWOULDBLOCK, I think.
Consider using qemu_write_full() instead of open-coding
the retry loop ?

thanks
-- PMM


On Tue, Jan 22, 2019 at 07:41:16AM -0500, Bandan Das wrote:
> 
> qemu_write_full takes care of partial blocking writes,
> as in cases of larger file sizes
> 
> Suggested-by: Peter Maydell <email address hidden>
> Signed-off-by: Bandan <email address hidden>

Hmm, doesn't apply, and git fails to do a 3way merge too due to unknown
sha1.

cheers,
  Gerd



On Thu, Jan 24, 2019 at 03:19:03AM -0500, Bandan Das wrote:
> Gerd Hoffmann <email address hidden> writes:
> 
> > On Tue, Jan 22, 2019 at 07:41:16AM -0500, Bandan Das wrote:
> >> 
> >> qemu_write_full takes care of partial blocking writes,
> >> as in cases of larger file sizes
> >> 
> >> Suggested-by: Peter Maydell <email address hidden>
> >> Signed-off-by: Bandan <email address hidden>
> >
> > Hmm, doesn't apply, and git fails to do a 3way merge too due to unknown
> > sha1.
> 
> Oops, sorry, I realize now this is on top of the write buffer breakup patches.

Hmm, they are queued up already, so that should have worked.

> Should I resend a v2 on top of master and send a v3 for the write buffer breakup
> patches ?

Can you just send a single series with both this fix and the breakup
patches, against latest master?

thanks,
  Gerd



Fixed by commit 49f9e8d660d4 which will be in QEMU 4.0.