On 05.12.22 16:54, Marko Mäkelä wrote:
If NumCamSlots is 0, SlotPriority[] is never accessed.
So why allocate memory for it if it is never used?
Allocating a variable-length array of length 0 is undefined behaviour.
The compiler is allowed to assume NumCamSlots>0 and optimize something
based
On 06.12.22 14:25, Marko Mäkelä wrote:
...
Maybe the simplest way to silence the warning would be to bloat the
variable-length array with 1 extra element, wasting sizeof(int) bytes of stack
space:
int SlotPriority[NumCamSlots + 1];
OK, so this is it:
--- device.c2022/01/24 16:53:45
On 06.12.22 12:24, Marko Mäkelä wrote:
...
diff --git a/dvbsubtitle.c b/dvbsubtitle.c
index c1dfef4d..2d22d963 100644
--- a/dvbsubtitle.c
+++ b/dvbsubtitle.c
@@ -1770,6 +1770,8 @@ void cDvbSubtitleConverter::FinishPage(cDvbSubtitlePage
*Page)
return;
int NumAreas;
tArea *Areas =
Tue, Dec 06, 2022 at 01:24:09PM +0200, Marko Mäkelä wrote:
The first attached patch includes your suggested fixes and nothing that
you opposed so far. The second attached patch fixes the following 2
issues. I agree that the NumCamSlots==0 case could be solved in a nicer
way.
I tried to make
Mon, Dec 05, 2022 at 04:08:45PM +0100, Klaus Schmidinger wrote:
Instead if typecasting I guess I'll rather do it this way:
This worked as well.
If x2 ever becomes negative, something else must have gone wrong.
The actual culprit is cDvbSubtitleConverter::FinishPage(), which was
invoking
Hi Klaus,
Tue, Dec 06, 2022 at 12:05:02AM +0100, Klaus Schmidinger wrote:
In cDevice::GetDevice() SlotPriority[] is never touched if NumCamSlots
is 0. So the compiler may assume whatever it wants in that case, it
won't matter. Or can you show a case where it actually misbehaves?
Because I am