Bug 1109541 - dtv-scan-tables differs between architectures
Summary: dtv-scan-tables differs between architectures
Status: IN_PROGRESS
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other (show other bugs)
Version: Current
Hardware: Other openSUSE Factory
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Stefan Seyfried
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1109534
  Show dependency tree / graph
 
Reported: 2018-09-25 05:06 UTC by Bernhard Wiedemann
Modified: 2019-11-04 14:09 UTC (History)
2 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
diff (3.48 KB, text/plain)
2018-09-25 05:06 UTC, Bernhard Wiedemann 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Wiedemann 2018-09-25 05:06:32 UTC 
Created attachment 784073 [details]
diff

seems to be a bug in the 32-bit codepath

see bug 1109534 for background
Comment 1 Stefan Seyfried 2018-09-28 09:23:16 UTC 
dtv-scan-tables package uses dvb-format-convert from dvb-utils package (source v4l-utils) to create the data files.

So I'd guess the real code problem is in v4l-utils (checking right now...)
Comment 2 Bernhard Wiedemann 2019-11-04 09:49:42 UTC 
Issue still exists in current builds (from 2019-06-12)
Comment 3 Stefan Seyfried 2019-11-04 13:45:36 UTC 
Note to self:

   unsigned int foo = atol(bar);

with input bar="(unsigned int)-1" (= "0xffffffff", = "4294967295") is not a good idea on 32 bits architecture.
Because it returns only "LONG_MAX", which is 0x7ffffff.
Comment 4 Stefan Seyfried 2019-11-04 14:09:08 UTC 
sr#745189 to devel project, letting the maintainers decide.

Tomáš: I tested in home:seife:testing, with this patch the generated scan tables are identical.

The stream_id field that was added before on i586 was 0x7ffffff (which is LONG_MAX) instead of 0xffffffff which is specified in input file.

I have not dug completely into the code, but I guess that STREAM_ID=-1 / UINT_MAX gets filtered out as invalid while 0x7fffffff gets written to output as it is somewhat "valid". But it is not what was specified in input, but the error code of atol().