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 inc

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 no

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

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 wrote: > > Alignment is definitely possible. There was a similar p

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 com

[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 Interest@qt-project.org https://lists.