Am Mon, 25 Apr 2022 14:11:18 +0200 schrieb Pavel Sanda <sa...@lyx.org>:
> On Mon, Apr 25, 2022 at 10:10:26AM +0200, Kornel Benko wrote: > > Am Sun, 24 Apr 2022 21:45:13 +0200 > > schrieb Pavel Sanda <sa...@lyx.org>: > > > > > On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote: > > > > Try to use > > > > $ lyx -dbg > > > > it should display > > > > ... > > > > 4294967296 debug ... > > > > then 1L would be correct. > > > > > > Seems to be correct now. > > > > > > > > > +// Make sure at compile time that sizeof(unsigned long long) >= 8 > > > > > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : > > > > > > -1]; > > > > > > > > > > long long is supposed to be able to represent values between -(2^63 > > > > > -1) to 2^63 > > > > > -1 so I do not think this check is necessary. > > > > > > > > I wanted to be sure ... > > > > > > I do not see any ambiguity here. Mention of long long int goes back at > > > least to > > > ANSI C norm from 1998 and the range of 2^64 is already there. > > > > > > Pavel > > > > Pavel, I'd like to see the output of the following c++ source > > #include <stdint.h> > > > > compiled with > > $ c++ -E -g3 > > The machine where it broke shows this: > https://pastebin.com/ubZVNKdr The output shows that your machine defines uin64_t as typedef unsigned long int uint64_t; at /usr/include/stdint.h:56 So, the include of "stdint.h" would be sufficient. > > because I prefer to use something like uint64_t over 'unsigned long long'. > > I dislike it because we use long long on bunch of different places in our > code already. This is introducing not yet used type depending on special > header. > This might break on whatever strange arch ppl try to compile for no obvious > gain. > > > Other than this, if the test is really too itching, I am not opposing too > > strong to > > remove it. > > I just pointed out that long long needs to contain 64 bit range as defined by > C(++) > standard. At about the same time as stdint.h was introduced to make the int-types portable. (At least, that is how I understood) > Can you explain to me what is the reason for "weakly opposing" it? Yes, the code does no harm, only gave me a guaranty. I read somewhere that 64 bit for long long was a 'should' and not a 'must'. But int64_t _has_ to contain valid 64 bits. > Pavel Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
pgpRmef5x8oca.pgp
Description: Digitale Signatur von OpenPGP
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel