Our code has structs that were set up in 16-bit processor days, and it uses an object database library that probably started for 8-bit. Most structs were easy to revise for 4 and 8 byte alignments, but some parse data from disk. Those are the ones that get #pragma pack (2). Any speed hit is tiny compared to disk access time.
We still need those old structs for a one-time file conversion of user data that may date back to the 90s. The code reads old structs, then writes newer ones with modern alignment. Sometimes arrays of them. It worked fine in Qt5. In Qt6 for ARM, 2-byte aligned structs mostly work, but if they go through a void pointer they don't cast back properly. No specific system error, just our code sanity-checking and reporting the nullptr. There's only a few places where we use function pointers with void parameters. They are hard to debug so it's fine to rewrite the last of them. But that database library also loses structs when coming back from (the) void. It also worked in Qt5, but breaks for Qt6 on ARM. Their code is a nightmare, and we only need it once to read old files. A rewrite would take years. Does that make sense? We haven't built with Qt6 for Windows yet but will do that soon. It may help narrow down where the problem lies. Thanks, Casey McDermott TurtleSoft.com On Tue, Jun 20, 2023 at 6:00 AM <[email protected]> wrote: > Send Interest mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.qt-project.org/listinfo/interest > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Interest digest..." > Today's Topics: > > 1. QDateTime::fromString does not work with Qt::RFC2822Date > (Alexander Dyagilev) > 2. Re: Void pointers for Mac ARM (Turtle Creek Software) > 3. Re: Void pointers for Mac ARM (coroberti) > 4. Re: QDateTime::fromString does not work with Qt::RFC2822Date > (Axel Spoerl) > 5. Re: QDateTime::fromString does not work with Qt::RFC2822Date > (Alexander Dyagilev) > 6. Re: Void pointers for Mac ARM (Thiago Macieira) > > > > ---------- Forwarded message ---------- > From: Alexander Dyagilev <[email protected]> > To: Qt Interest <[email protected]> > Cc: > Bcc: > Date: Mon, 19 Jun 2023 13:51:37 +0300 > Subject: [Interest] QDateTime::fromString does not work with > Qt::RFC2822Date > Hi guys, > > Am I an idiot, or is it really QDateTime::fromString which is broken > since at least Qt 6.2.4 ? > > I've created the bug report here: > https://bugreports.qt.io/browse/QTBUG-114681 > > > > > > ---------- Forwarded message ---------- > From: Turtle Creek Software <[email protected]> > To: coroberti <[email protected]> > Cc: [email protected] > Bcc: > Date: Mon, 19 Jun 2023 07:13:51 -0400 > Subject: Re: [Interest] Void pointers for Mac ARM > Alignment is definitely possible. There was a similar problem earlier in > execution, and that had pointers to 2-byte aligned structs. > We just rewrote the ugly void* code rather than try to diagnose it > further. The debugger showed the correct address but failed to cast a > parameter. > > Can the ARM compiler handle #pragma pack (2) ? > > Thanks, > Casey McDermott > TurtleSoft.com > > On Mon, Jun 19, 2023 at 2:50 AM coroberti <[email protected]> wrote: > >> On Sat, Jun 17, 2023 at 8:12 PM Turtle Creek Software >> <[email protected]> wrote: >> > >> > Our app contains some old C-ish C++ code from an early 90's database >> called NeoAccess. It often uses function pointers with void pointers as >> parameters. Their code works OK for Mac & Windows, when built with the >> latest Qt5 on Intel. >> > >> > The code also builds OK with the latest Qt6, but running it on an M1 >> Mac gives run-time errors. Void pointers to structs and objects don't cast >> properly and stay null. We haven't tried Qt6 on Windows yet but will do >> that soon. >> > >> > Any ideas on how to fix it? We've abandoned NeoAccess for our new app >> but still need it to convert data from existing files. Rewriting their >> code is a nightmare. >> >> Casey, >> Perhaps, checking the alignment of the void* pointers in question >> could provide you with some clues. >> >> Kind regards, >> Robert Iakobashvili >> ............................ >> > > > > ---------- Forwarded message ---------- > From: coroberti <[email protected]> > To: Turtle Creek Software <[email protected]> > Cc: [email protected] > Bcc: > Date: Mon, 19 Jun 2023 14:17:24 +0300 > Subject: Re: [Interest] Void pointers for Mac ARM > Sorry, no knowledge about the pragma and how it's handled by clang. > > I'd make it all 8-bytes aligned on 64-bit. > > Kind regards, > Robert Iakobashvili > ............................ > > On Mon, Jun 19, 2023 at 2:14 PM Turtle Creek Software > <[email protected]> wrote: > > > > Alignment is definitely possible. There was a similar problem earlier > in execution, and that had pointers to 2-byte aligned structs. > > We just rewrote the ugly void* code rather than try to diagnose it > further. The debugger showed the correct address but failed to cast a > parameter. > > > > Can the ARM compiler handle #pragma pack (2) ? > > > > Thanks, > > Casey McDermott > > TurtleSoft.com > > > > On Mon, Jun 19, 2023 at 2:50 AM coroberti <[email protected]> wrote: > >> > >> On Sat, Jun 17, 2023 at 8:12 PM Turtle Creek Software > >> <[email protected]> wrote: > >> > > >> > Our app contains some old C-ish C++ code from an early 90's database > called NeoAccess. It often uses function pointers with void pointers as > parameters. Their code works OK for Mac & Windows, when built with the > latest Qt5 on Intel. > >> > > >> > The code also builds OK with the latest Qt6, but running it on an M1 > Mac gives run-time errors. Void pointers to structs and objects don't cast > properly and stay null. We haven't tried Qt6 on Windows yet but will do > that soon. > >> > > >> > Any ideas on how to fix it? We've abandoned NeoAccess for our new > app but still need it to convert data from existing files. Rewriting their > code is a nightmare. > >> > >> Casey, > >> Perhaps, checking the alignment of the void* pointers in question > >> could provide you with some clues. > >> > >> Kind regards, > >> Robert Iakobashvili > >> ............................ > > > > > ---------- Forwarded message ---------- > From: Axel Spoerl <[email protected]> > To: Qt Interest <[email protected]> > Cc: > Bcc: > Date: Mon, 19 Jun 2023 11:27:03 +0000 > Subject: Re: [Interest] QDateTime::fromString does not work with > Qt::RFC2822Date > Hi Alexander, > the reason for the assertion is the "GMT" string. RFC2822 expects the time > zone to be specified as an offset from UTC (e.g. "-0200"). If no offset is > specified, the timezone is assumed to be UTC. > UTC (or GMT) as an explicit specification as a string would not make much > sense and is therefore not tolerated. > That's the format, QDateTime::fromString() accepts. > Not sure, if and why UTC/GMT was accepted prior Qt 6, if that's a bug or > even a regression. I'll check this and respond to the Jira ticket. > Cheers > Axel > > ------------------------------ > *Von:* Interest <[email protected]> im Auftrag von > Alexander Dyagilev <[email protected]> > *Gesendet:* Montag, 19. Juni 2023 12:51 > *An:* Qt Interest <[email protected]> > *Betreff:* [Interest] QDateTime::fromString does not work with > Qt::RFC2822Date > > Hi guys, > > Am I an idiot, or is it really QDateTime::fromString which is broken > since at least Qt 6.2.4 ? > > I've created the bug report here: > https://bugreports.qt.io/browse/QTBUG-114681 > > _______________________________________________ > Interest mailing list > [email protected] > https://lists.qt-project.org/listinfo/interest > > > > ---------- Forwarded message ---------- > From: Alexander Dyagilev <[email protected]> > To: Axel Spoerl <[email protected]>, Qt Interest <[email protected]> > Cc: > Bcc: > Date: Mon, 19 Jun 2023 14:42:35 +0300 > Subject: Re: [Interest] QDateTime::fromString does not work with > Qt::RFC2822Date > > Thanks for the response! > > > Well, I don't really know if it conforms to the standard or not, but this > "GMT" string is used by web servers (at least some of them). It's parsed > with no issues using JavaScript. > > > We use QDateTime::toString to parse HTTP responses. Our users are > complaining it's not working anymore, that's why I had to create this > report.. > > > On 6/19/2023 2:27 PM, Axel Spoerl via Interest wrote: > > Hi Alexander, > the reason for the assertion is the "GMT" string. RFC2822 expects the time > zone to be specified as an offset from UTC (e.g. "-0200"). If no offset is > specified, the timezone is assumed to be UTC. > UTC (or GMT) as an explicit specification as a string would not make much > sense and is therefore not tolerated. > That's the format, QDateTime::fromString() accepts. > Not sure, if and why UTC/GMT was accepted prior Qt 6, if that's a bug or > even a regression. I'll check this and respond to the Jira ticket. > Cheers > Axel > > ------------------------------ > *Von:* Interest <[email protected]> > <[email protected]> im Auftrag von Alexander Dyagilev > <[email protected]> <[email protected]> > *Gesendet:* Montag, 19. Juni 2023 12:51 > *An:* Qt Interest <[email protected]> <[email protected]> > *Betreff:* [Interest] QDateTime::fromString does not work with > Qt::RFC2822Date > > Hi guys, > > Am I an idiot, or is it really QDateTime::fromString which is broken > since at least Qt 6.2.4 ? > > I've created the bug report here: > https://bugreports.qt.io/browse/QTBUG-114681 > > _______________________________________________ > Interest mailing list > [email protected] > https://lists.qt-project.org/listinfo/interest > > _______________________________________________ > Interest mailing > [email protected]https://lists.qt-project.org/listinfo/interest > > > > > ---------- Forwarded message ---------- > From: Thiago Macieira <[email protected]> > To: [email protected] > Cc: > Bcc: > Date: Mon, 19 Jun 2023 08:30:54 -0700 > Subject: Re: [Interest] Void pointers for Mac ARM > On Monday, 19 June 2023 04:13:51 PDT Turtle Creek Software wrote: > > The debugger showed the correct address but failed to cast a > > parameter. > > > > Can the ARM compiler handle #pragma pack (2) ? > > What does this have to do with casting? It would really help if you gave > exact > error messages. That includes warnings about ignored / unrecognised > pragmas. > > Anyway, why do you want #pragma produce_slow_memory_accesses? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Cloud Software Architect - Intel DCAI Cloud Engineering > _______________________________________________ > Interest mailing list > [email protected] > https://lists.qt-project.org/listinfo/interest >
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
