Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69982
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding |
| Date | 2019-11-22 15:04 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <qr8pu5$657$1@dont-email.me> (permalink) |
| References | (5 earlier) <qr7v3c$lvv$1@dont-email.me> <qr86ov$q9d$1@dont-email.me> <qr8deq$tm2$1@dont-email.me> <qr8gep$esf$1@dont-email.me> <qr8jeg$v7n$1@dont-email.me> |
On 22/11/2019 13:14, Soviet_Mario wrote:
> Il 22/11/19 12:23, David Brown ha scritto:
>> On 22/11/2019 11:31, Soviet_Mario wrote:
>>> Il 22/11/19 09:37, David Brown ha scritto:
>>>> On 22/11/2019 07:26, Christian Gollwitzer wrote:
>>>>> Am 21.11.19 um 17:20 schrieb Paavo Helde:
>>>>>> On 21.11.2019 13:53, Soviet_Mario wrote:
>>>>>>> My only requirement is that the plain native type BYTE used in
>>>>>>> gambas
>>>>>>> code that calls the C++ static library and that expects a 8-bit wide
>>>>>>> unsigned integral, find its matching type in the C++ code, as they
>>>>>>> need
>>>>>>> to share bitmaps and transparency maps.
>>>>>>
>>>>>> This is easy, use unsigned char or std::uint8_t.
>>>>>>
>>>>>>> The bitmaps use 32-bit packed colors+alpha channel, so I was
>>>>>>> assuming no
>>>>>>> difficulty in exchange.
>>>>>>
>>>>>> This is more tricky because the size of int or long varies much more
>>>>>> than char. For example, long is 32 bits in 64-bit MSVC and 64 bits
>>>>>> with 64-bit gcc on Linux.
>>>>>>
>>>>>> However, for your purposes std::uint32_t should work fine.
>>>>>
>>>>> Why not
>>>>>
>>>>> #pragma pack(1)
>>>>> struct pixel {
>>>>> uint8_t red, green, blue, alpha;
>>>>> }
>>>>>
>>>>> ? That would make more sense to me than uint32_t and bit-twiddling to
>>>>> get the channel values.
>>>>>
>>>>> Christian
>>>>
>>>> If you are using "pragma pack" (or gcc "packed" attribute), you are
>>>> probably doing something wrong. It can have some uses when dealing
>>>> with
>>>> file formats
>>>
>>> it is exactly this second case : two programs have to communicate and
>>> store picture files in a compact way (and if I'll manage to, even
>>> exchange such pictures loaded in memory) upon a single big binary
>>> "fread" from disk or save with a single raw "fwrite" to disk.
>>> I can't find it acceptable that the DISK layout and RAM layout may
>>> differ as to packing aspects.
>>> Non only for the waste of space (a large waste as pictures could be some
>>> tens megapixels), but as in such case I would have to read/write only
>>> single elements at a time. Unacceptable (*).
>>> I must be allowed to load and save fast and in a single shot, so 1:1
>>> mapping RAM<=>DISK.
>>> This requirement is underogatable, even if I agree with all other
>>> remarks you make afterwards ...
>>
>> You have a struct with byte data - making it packed is /useless/. There
>> is /never/ any advantage in that.
>>
>> If the structure contains data of different sizes, then first check if
>> there really are padding or alignment issues. Most structures used for
>> file formats are "naturally aligned" - the people who designed the
>> structures are smart enough to make sure that every 2-byte data item is
>> at an even address, every 4-byte data item is at a multiple of 4
>> address, and so on. There are exceptions, especially for some older
>> formats from the days of 16-bit cpus, but it is often the case.
>>
>> And if it is the case here, then making it "packed" is useless at best,
>> and can easily be a significant disadvantage.
>>
>> All of what you have written here is "premature optimisation" - it is
>> knee-jerk thinking "I've got a file structure, I must use packed" rather
>> than looking at what is actually relevant or helpful. At the moment,
>> you haven't the faintest clue as to whether using a packed struct makes
>> a real and measurable difference that is worth the cost -
>
> sure I have no idea, I put the pragma there just for "precaution"
> what cost is that supposed to have ?
>
I've told you in several posts what the costs are. "Packed" is /not/ a
"precaution", nor is using a struct with a bitfield instead of uint8_t.
If you don't know what you are doing, fine - if I understand you
correctly, you are experienced with gambas programming but new to C++.
So /ask/ (and please read the answers). Don't guess, or grab the first
thing that you find from a google search. And when the more experienced
people in a group like this all say "don't use packed" and "use
uint8_t", then that is what you should do. Ask /why/, and try to learn
- and once you do understand "pack", when it can be useful, when it is
useless, when it is worse than useless, what it does, and what it costs
- /then/ you can decide that because you know the full situation better
than we do, you still want to use it against general advice.
"Packed" is not a precaution - it is a last choice solution when you
have nothing better and know you can't write the code as well without
it. (That might mean you can't write the code as quickly or clearly
without it, which is fair enough - /if/ you are sure it is necessary.)
>
>> even if we
>> assume the file format details are not aligned. You haven't done any
>> timings of real-world usage of your system to see if this is a
>> bottleneck. You haven't tested alternatives like "mmap", or existing
>> libraries.
>
> I'm writing from scratch almost, but It will be a very simple library
>
>> You haven't compared the time it takes to load or save the
>> file with the time it takes to do your processing.
>
> sure, but I'll have to do both in any case :)
> It's a non-sense comparison though
> I just thought of
> read/write all-at-once vs pixel by pixel (and choose I)
>
> no use in knowing if I spend more time applying transformations on the
> loaded picture vs saving or loading it. They are sequential mandatory
> operations
Of course there is use in knowing this, if speed is an issue. If the
processing takes 1000 times as long as the loading and saving, then you
know that putting the slightest effort into speed optimisation for file
access is a waste of effort - your time would be better spent trying to
shave 0.1% off the processing time than increasing the speed of the file
access by orders of magnitude.
And if your file format contains non-aligned members, then the simplest
and easiest way to improve and simplify the code, and improve the speed
of several parts, is to fix the file format. Make sure the members are
aligned (add explicit dummy members if necessary) - then forget you ever
heard of "pragma pack".
>
>
>> You haven't compared
>> the time it takes to pack or unpack the format to the time it takes to
>
> chosen not to pack/unpack anything actually, as I'm hoping the RAM /
> disk layout are the very same raw binary.
> I was asking help in making sure this was (not if it was useful or not)
No one can tell you if it is the same without knowing the file format.
There is nothing wrong with having the ram and disk layout the same -
often that is a very convenient and efficient choice. But if the disk
layout is not directly usable in ram, then it often is /not/ a
convenient and efficient choice - and if it /is/ usable directly in ram,
you don't need or want "pack".
However you look at it, "pack" is usually (but not always) the wrong
choice. You should only consider it once you have eliminated better
alternatives.
As for asking for help here, you are getting the help you need even if
it is not exactly what you asked for. It's as though you said "I need a
new toothbrush. Can you tell me how to get to the toy shop?" It is
conceivable that a toy shop might have toothbrushes, but it is very
unlikely to be a good choice. Would you not rather have people say "You
don't want to go to a toy shop. You want to go to a chemist - this is
how you get there" ?
>
>> read or write it from the disk. You haven't compared the time the
>> processing takes for a "packed" struct to how it would run with an
>> unpacked struct.
>
> forgive me : how to read an all packed file in an array of UNpacked data
> of different layout, in a single read operation ? I can't figure out this
>
First, you take a step back. You look to see if the packed file really
is "packed", in the sense of having unaligned data that would have
padding in a normal struct. I have seen no answer to this (unless it is
later in this post), despite asking this /crucial/ question.
If the format is already good, you are done. One memcpy, or read from
the file directly to a suitable buffer, or memmap to the file directly
(no reading or writing needed).
If the format is bad, the next step is to consider changing the format.
This would be good for all parts of the system. When the format is
changed, you are done. Again, I have had no answer to whether this is
possible.
If the format is bad, and cannot be fixed, then you have to write reader
and writer functions that unpack and pack the data into the right
formats. Reader and writer functions are common for all sorts of
reasons - you already have something to handle starting with the file
header and then allocating memory depending on the size. It is very
normal to have a function that reads in the data format and uses it to
populate an internal format. Perhaps your file format uses 8-bit
unsigned data for colour channels, but your internal format uses
floating point because that suits your processing needs. Perhaps the
file format uses run-length encoding for smaller files, and you want to
expand it to a raw array. There are all sorts of things that go on in
typical reader functions. Making them a "single operation", whatever
that might mean, is rarely relevant - code that uses these functions has
a "single operation" of calling the reader function.
>>
>> (Yes, I realise I have made a lot of claims here about what you have and
>> haven't done. From your posts, I think they are almost certainly true.
>> If I am wrong there, let me know.)
>
> no problem, most are right.
> Some are irrelevant imho
Perhaps - but not necessarily the ones you think are irrelevant. IMHO,
of course.
(And to be clear - I did not right this to be rude, or insulting, or
demoralising, and I hope it did not come across that way. I am writing
to push you to think about things that are important here, but which I
feel you are skipping. The aim is that you learn more, and that you can
write better code that is clear, correct and efficient without wasting
effort on poorer techniques.)
>
>>
>>
>> If you want to tell me that using "pack" makes your development process
>> simpler and the code easier, that's fine
>
> I don't know. Just searching a way to do binary read/write in one single
> shot directly to/from RAM without any conversions.
Doing this all "in one single shot" should not be an aim. Doing it in a
way that makes the code simple and clear, easy to develop, easy to read
and easily correct should be your aim. Quite possibly your real goal
would be easiest achieved by using a standard format (like PNG) and
existing libraries for gambas and C++. Call the one function - simple
and clear.
> And have a RAM layout simple enough not to require bitwise masking to
> locate fields (the drawback of a pure "bit fields" solution)
>
Why would you want to bring bitfields into this?
>> - I'll believe that, and it is
>> a perfectly good reason for using it. But if you try to tell me you are
>> doing it for run-time speed reasons, then you are wrong. Measure first,
>> find out if it really is too slow, find your /real/ bottlenecks, /then/
>> start looking for ways to improve the throughput.
>
> I don't have any running stuff by now, as I'm still in the design time.
> But I could not redesign the BASIC disk and data structure later, so i
> MUST make some premature optimization now as it affects the very base of
> the pillar.
>
Fair enough. So get it /right/ by designing the right data structure
/now/, rather than picking a bad structure from the start.
>>
>>>
>>>
>>> (*) well actually I do not make strictly a single load/save as stated.
>>> First I save/load a very small descriptor with WIDTH/HEIGHT stored as 16
>>> bit integers, then, aware of the array size of the buffer, alloc and
>>> fread or fwrite down.
>>>
>>> It's a very "stupid" non standard format, but I don't need to export
>>> this directly. When in gambas I save using its native functions. The C++
>>> engine is just supposed to transform pictures and save in raw format.
>>>
>>
>> So don't make stupid formats. Make /simple/ formats,
>
> I meant the same actually.
> I store 16 bit width, 16 bit height, and then a compact rectangular
> array o 32 bit pixels (8+8+8+8 for 3 color channels + transparency) per
> each pixel.
>
> it is is not completely "naturally aligned", but the header and the
> "body" are placed apart, in memory, and read/written in distinct file
> operations.
So make it "naturally aligned". What will be the cost? A couple of
extra unsused padding bytes, added manually?
struct pixel {
uint8_t red, green, blue, alpha;
};
struct picture_format {
uint64_t key; // Always 0x0064727574636950ull
uint8_t file_type_version;
uint8_t padding1;
uint16_t height;
uint16_t width;
uint16_t padding2;
pixel pixeldata[];
};
Pick an alignment for the structure - 32-bit or 64-bit are good choices.
Start with a member of that size for convenience - I like a constant
marker to make it easy to tell that you are using the right file type.
(The value here is the string "Picture".) Make sure everything is
aligned sensibly. Add padding members manually and explicitly to keep
it clear - then there is never any doubt. (These may later be re-used
for extra information in later file format versions.) Make sure
separate blocks, such as the header and the data section, each are
aligned to the main large alignment for efficiency.
>
> So I ask you, when I call NEW operator for an array of "pixel" structs,
> is it naturally aligned or not ?
Yes, as long as you don't faff about with "packed" stuff. Then you
don't know.
>
>
>> and non-standard
>> formats, if that is what is best for the job. But don't make a stupid
>> format.
>
> I called it stupid in place of the simplest as possible.
> There are no "tags" included as this is only an "internal" (and
> personal) format for intermediate raw data.
> It does not seem to be more sophisticated than this.
Then it is inexcusable to have a format that needs "packed". That just
means totally pointless complications, inefficiencies, and non-portable
code.
If you have learned nothing else from this conversation, hopefully you
have learned that much.
>
>> If the fields in the struct are not properly ("naturally")
>> aligned, change the format so that they are. That will help the gambas
>> side, help the C++ side, and mean you don't have to faff around with
>> "pack" extensions /or/ with extra packing and unpacking stages.
>>
>>
>
>
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-20 19:55 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-20 20:12 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-20 22:33 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-20 20:22 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-20 19:34 +0000
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 00:54 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-20 16:27 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Manfred <invalid@add.invalid> - 2019-11-21 01:48 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 04:09 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-20 17:44 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 04:14 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-20 22:03 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 01:00 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-21 13:22 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-21 11:30 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-21 22:54 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-20 23:28 +0200
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-20 15:48 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Reinhardt Behm <rbehm@hushmail.com> - 2019-11-21 10:33 +0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-21 13:25 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-20 22:32 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-20 22:43 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 12:53 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-21 18:20 +0200
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-21 18:07 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-11-21 17:34 +0000
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Christian Gollwitzer <auriocus@gmx.de> - 2019-11-22 07:26 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-22 00:37 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 10:10 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 02:23 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 12:38 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Manfred <noname@add.invalid> - 2019-11-22 17:13 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 18:48 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 10:49 -0500
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 10:52 -0500
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:51 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 11:20 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-22 10:00 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 09:37 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 01:37 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 11:40 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 04:55 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 15:18 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-22 07:23 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 16:34 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding scott@slp53.sl.home (Scott Lurndal) - 2019-11-22 15:16 +0000
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-23 05:11 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 10:56 -0500
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Öö Tiib <ootiib@hot.ee> - 2019-11-23 07:03 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 11:31 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 12:23 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 13:14 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding David Brown <david.brown@hesbynett.no> - 2019-11-22 15:04 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-22 19:35 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 14:11 -0500
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-23 00:25 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-22 23:56 -0500
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-23 11:12 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-23 14:51 +0200
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-25 11:45 -0500
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-22 22:04 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-23 11:26 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-23 12:27 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-24 00:54 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Keith Thompson <kst-u@mib.org> - 2019-11-23 17:06 -0800
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Soviet_Mario <SovietMario@CCCP.MIR> - 2019-11-24 12:10 +0100
Re: [QT creator on "nix"] - getting a strict 8 bit (1 byte) array with no padding Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 13:21 -0800
csiph-web