Most likely I made an error in the rtfGrammer.y file on line 212. The statement
"$$ = 3" should just read "3". I will correct that and regenerate the dependent
files as soon as I am back home, that is sometimes next weekend. You could
check whether this is the case by looking at your RTF files,
Hi,
after checking the strange encoding bug, I have another strange error in
GWorkspace which is either new or I never noticed.
I get several of these:
2020-05-26 09:37:22.971 GWorkspace[13276:100105] Setting unknown
encoding 1
this is not 32bit or 64bit dependent at all.
The only
Hi,
Richard Frith-Macdonald wrote:
My best guess would be either something like NSNotFound (0x on 32bit
0x on 64bit) being encoded, or a negative integer accidentally
being encoded as unsigned.
Apart from that it's hard to find integer values which would break the
Hi,
Wolfgang Lux wrote:
Well, you've missed out the one that should have worked:-)
-2147483648LL
Note that suffix L mark a long value, which is just 32 bits on a 32-bit system
the long type. So to get a 64-bit literal you need to ask for a long long value.
ah yes! At first I didn't think
> Am 25.05.2020 um 23:57 schrieb Riccardo Mottola :
>
> What is interesting, if gdb follows the same literal rules and promotions of
> GCC:
>
> (gdb) p (int64_t)-2147483648
> $8 = 2147483648
> (gdb) p (int64_t)-2147483648l
> $9 = 2147483648
> (gdb) p (int64_t)-2147483648L
> $10 =
> On 25 May 2020, at 22:57, Riccardo Mottola wrote:
> Looking up on the internet, I found the explanation is that the literal is
> only the number part without signed, regarless if it is a signed or unsigned
> decimal. Then the - operator is performed. For this reason it is usually
>
> On 25 May 2020, at 19:38, Riccardo Mottola wrote:
>
> Hi,
>
> On 25/05/2020 09:50, Fred Kiefer wrote:
>>> The first "halt" I get is when loading Attributes.gorm of GWorkspace's
>>> Inspector
>>>
>> Looks like your archive has a value that gets encodes as an NSInteger and
>> this is 32
