Aleksej Saushev <a...@inbox.ru> writes:
[...] | > This would require that I have a C99 compiler and library or at least | > a compiler and library that understand those times. I know that on | > open-solaris, that is a nightmare to get right. I would have expected | > that on *BSD, a long is 64-wide if there support for 64-bit integer | > datatypes... | | Alright, let's try another way. scanf(3) lists this: | | q Indicates that the conversion will be one of dioux or n and the | next pointer is a pointer to a quad_t (rather than int). | | /usr/include/sys/types.h:typedef uint64_t u_quad_t; /* quads */ | /usr/include/sys/types.h:typedef int64_t quad_t; | | stdlib.h pulls these definitions in. It is so on NetBSD and Dragonfly, | I expect it to be on FreeBSD same way. | | OTOH, Dragonfly documentation declares it deprecated. | | Dragonfly scanf(3) mentions this instead: | | ll (ell ell) | Indicates that the conversion will be one of dioux or n and the | next pointer is a pointer to a long long int (rather than int). | | Same on FreeBSD. | | Not so on NetBSD, though test program using "%lld" does work. | I consider it documentation bug. Now, I'm wondering why I'm not using C++ :-( In C++, I would just write 'cin >> x' and the compiler would sort out of the platform dependencies/dicrepencies for me... -- Gaby ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
