[Interest] Interest Digest, Vol 92, Issue 5

[Roland Hughes]

On 5/5/19 5:00 AM, interest-request at qt-project.org wrote:
>> It makes for a lot of
>> documentation in the embedded system world where every static_cast<>()
>> has to be documented in the code and justified in a formal code review
>> which produces even more documentation. It also makes for some fancy
>> dancing on 32-bit embedded targets where a uint would be big enough to
>> hold the size of something but an int falls short.
> No, the size of something definitely fits in int on 32-bit systems. And why do
> you need to do any static_cast in the first place?

Virtually every English speaking embedded system shop uses the Barr 
standard.

https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard

While each shop tweaks it for C++, C-style casts are explicitly 
forbidden (at least in every shop I've been at). None can make it 
through formal review. In their C++ presentation slides the Barr group 
is a bit softer on their wording. Less so in actuality, but the slides 
are recorded forever.

https://barrgroup.com/Embedded-Systems/How-To/Getting-Started-With-Cplusplus

========

Next is type casting, when we use C style cast, there are times when we 
are just kind of smashing “Square peg into a round a hole” this is 
potentially dangerous. Because C++ is a lot more finicky about type 
checking, the compiler will try to catch bad cast for us. There is no 
way of getting around the need to do type casting. As you move forward, 
consider always using the C++ cast operators, while these will look a 
little foreign and you may need to occasionally look up, which one to 
use in which situation, they are likely to ensure safe cast in your program.

As a general rule try to use static cast, this works for most data type 
casting. Occasionally you will need to use reinterpret cast. It’s a 
closest thing to a real C style cast. Since we don’t recommend using 
RTTI, dynamic cast really won’t be of concern to you and we won’t really 
talk about it here. And then the last one is const cast, which used with 
extreme caution, this is similar to casting away the constance of an 
object, so unless you really know that the object you are casting away 
the constness from can be done safely we recommend being very careful in 
this area.

========

As to size definitely fitting in an int, we will have to disagree. Sure, 
if a container is extremely short sighted and using an int internally to 
keep track of (and therefore limit) each allocated byte, effectively a 
neutered container, that statement would be correct. It never __SHOULD__ 
be correct.

https://code.woboq.org/gcc/include/limits.h.html

========

/* These assume 8-bit `char's, 16-bit `short int's,
    and 32-bit `int's and `long int's.  */
/* Number of bits in a `char'.        */
#  define CHAR_BIT        8

...

/* Minimum and maximum values a `signed int' can hold.  */
#  define INT_MIN        (-INT_MAX - 1)
#  define INT_MAX        2147483647
/* Maximum value an `unsigned int' can hold.  (Minimum is 0.)  */
#  define UINT_MAX        4294967295U

========

The biggest physical container one can have is half of maximum physical 
RAM. A small application can easily need more than that. We can use the 
old chestnut of image processing which needs to load an entire hi-res 
image into memory to do some kind of transformation, writing the 
transformed bytes to a file output stream.

More recently we can go back to the QSerialPort discussions happening on 
this list not all that long ago. The student level code examples trying 
to do all of the I/O in the main event loop with the buffer growing and 
growing in size.

=====

What is, when I ignore the ready read? Has the internal buffer a max size?
Because at the moment I have a memory leak and maybe it comes from that?

=====

They only get to use up to half of 32-bit system RAM before the wheels 
come off the cart. Since it was serial comm, in theory the device could 
stop sending for a bit, allowing them to catch up, but not if they've 
already maxed out the buffer and crashed. This horrible student design 
could have ran even longer, hoping the sender got tired long enough for 
them to catch up.

I quick banged this out using CodeLite on my KDE Neon desktop. Only have 
a few more minutes to myself before I have to begin work this Sunday 
morning. I also did not go digging through the Qt source code. Just 
basing this on your previous comment that "the size definitely fits in 
int." Could be headed down rabbit hole but given Qt 6 is in 
planning/dev, size should no longer "just be an int."

#include <stdio.h>
#include <limits.h>
#include <stdint.h>
#include <sys/sysinfo.h>

int main(int argc, char **argv)
{
     struct sysinfo my_sysinfo;

     printf("hello world\n");

     printf("INT_MAX: %d\n", INT_MAX);
     printf("UINT_MAX: %u\n\n", UINT_MAX);

     printf("INT32_MAX: %d\n", INT32_MAX);
     printf("UINT32_MAX: %ul\n\n", UINT32_MAX);

     printf("INT64_MAX: %ld\n", INT64_MAX);
     printf("UINT64_MAX: %llu\n\n", UINT64_MAX);

     sysinfo( &my_sysinfo);

     printf("totalram: %lu  totalswap: %lu  mem_unit: %u\n\n",
         my_sysinfo.totalram, my_sysinfo.totalswap, my_sysinfo.mem_unit);
     return 0;
}

=====

hello world
INT_MAX: 2147483647
UINT_MAX: 4294967295

INT32_MAX: 2147483647
UINT32_MAX: 4294967295l

INT64_MAX: 9223372036854775807
UINT64_MAX: 18446744073709551615

totalram: 25144201216  totalswap: 84807774208  mem_unit: 1

Press ENTER to continue...

=====

Even with 24Gig of RAM in the box I can't get a Qt container larger than 
INT_MAX

I ass-u-me qsizetype is going to fix the initial problem by compiling to 
a platform specific integer size. It needs to take it a step further and 
become a platform specific unsigned size, especially for QByteArray.

Why?

I haven't looked under the hood in a bit, but, just how many places do 
the tools/classes for some of the script kiddie favorites like XML and 
JSON have to bring in an entire file, then parse it? Unless that is 
somehow now parsing as it reads instead of requiring a hale and hole 
object, you still have a significant point of sporadic failure. Some 
files parse, others make it fall over.

Right now it is almost impossible to obtain, at a cost effective price, 
human-life-at-risk quality RAM modules smaller than 1Gig. We "could" get 
a 512Meg module but it cost more. The hardware designers left room and 
power for an even larger module because by the time we get close to 
production it is entirely possible the cheaper multi-year production 
contract will be for the 2Gig modules. The vendor has already let us 
know this as they are trying to spin down the older lines. I have to 
believe that within 2 years the smallest module vendors will be willing 
to provide a 7-10 year production contract on will be 4Gig and they will 
be trying to push device manufacturers to abandon 32-bit targets even 
though the use can't justify 64-bit. The power consumption is what has 
to improve. Many medical devices have to run 7-10 days on a single 
battery pack. I'm actually kind of surprised Inogen has been able to get 
away with only 5 hours for a double battery pack but it probably has to 
do with the fact it can be plugged in to charge while running.

https://www.inogen.com/pdf/96-06728-00-01-B-English-Only-Final-WEB.pdf

=====

The battery will power the Inogen One® G4 withoutconnection to an 
external power source.When fully charged,a single battery will provide 
up to 2.7 hours of operation;a double battery will provide up to 5 hours 
of operation.The battery recharges when properly installed in the Inogen 
One® G4 and the concentrator is connected to AC or DC power.Recharging 
time is up to 3 hours for a single battery and 5 hours for a double 
battery.See information in the “Battery Care and Maintenance”section.

=====

People are supposed to sleep for 8 hours.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com