Gabriel Dos Reis <g...@cs.tamu.edu> writes:
> Aleksej Saushev <a...@inbox.ru> writes:
>
> [...]
>
> | > | gmake[2]: Entering directory
> `/tmp/wip/openaxiom/work/open-axiom/src/lisp'
> | > | gmake[2]: *** gmake[2]: Entering directory
> `/tmp/wip/openaxiom/work/open-axiom/src/hyper'
> | > | oa_enable_lisp_profiling= nil
> | > | No rule to make target `core.o', needed by
> `../../i486--netbsdelf/lisp/core.o'../../libtool --mode=compile cc -c -o
> addfile.o -O2 -mfpmath=sse -msse3 -march=nocona -finline-functions
> -fomit-frame-pointer -ffast-math -I/usr/pkg/include -O2 -Wall
> -I../../src/include -I../../config -I. addfile.c
> | > | . Stop.
> | > |
> | > |
> | > | Also, I see this:
> | > |
> | > | hthits.c: In function 'handleFile':
> | > | hthits.c:292: warning: format '%ld' expects type 'long int *', but
> argument 4 has type 'time_t *'
> | > | hthits.c:292: warning: format '%ld' expects type 'long int *', but
> argument 4 has type 'time_t *'
> | > |
> | > | And I think it is a bad idea, because of:
> | > |
> | > | #define _BSD_TIME_T_ __int64_t
> | >
> | > which is not a standard data type. What is the corresponding scanf
> format?
> |
> | Probably the easiest way is using intmax_t ("%jd") or uintmax_t ("%ju")
> | and converting the input result.
>
> 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.
--
HE CE3OH...
------------------------------------------------------------------------------
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
