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 > 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. Can you explain to me what is the reason for "weakly opposing" it? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
