search for: inttypes

...++ 10 files changed, 30 insertions(+), 0 deletions(-) diff --git a/examples/c/decode/file/main.c b/examples/c/decode/file/main.c index e5138b4..f7efd9a 100644 --- a/examples/c/decode/file/main.c +++ b/examples/c/decode/file/main.c @@ -28,6 +28,9 @@ # include <config.h> #endif +#if HAVE_INTTYPES_H +#include <inttypes.h> +#endif #include <stdio.h> #include <stdlib.h> #include "FLAC/stream_decoder.h" diff --git a/examples/c/encode/file/main.c b/examples/c/encode/file/main.c index 1baad1d..bce9732 100644 --- a/examples/c/encode/file/main.c +++ b/examples/c/encod...

​Hi all, I am using llvmlite for pyvex and I want the output of my code (which is written based on llvmlite) to be like pyvex. In pyvex, (https://github.com/angr/pyvex). Considering pyvex, I tried to implement the following statements in pyvex to llvmlite: for stmt in irsb.statements: if isinstance(stmt, pyvex.IRStmt.Store): print "ST%s(%s) = %s" % (self.endness[-2:].lower(),

Ok, so I've been chugging away at AVX and added some new features in TableGen to facilitate writing generic patterns. Here's an example: //===----------------------------------------------------------------------===// // Dummy defs for writing generic patterns //===----------------------------------------------------------------------===// def SRCREGCLASS; def DSTREGCLASS; def MEMCLASS;

...gt; > > > >>Well, there is always __linux__, but that doesn't necessarily imply that >>we are on a Linux box with stdint.h.s >> >> > >Ok, I'll switch to that from the placeholder "LINUX". > > Inspection of DataTypes.h shows that inttypes.h is included before the test for linux / definition of __STDC_LIMIT_MACROS. This will not work, since stdint.h is implemented by including inttypes.h, which was already included the first time with __STDC_LIMIT_MACROS not defined. I think the best solution to this problem is to change DataTy...

On 2/1/2012 18:52, Erik de Castro Lopo wrote: > JonY wrote: > >> Alright, here's a quick fix, although it is more ugly than I remembered. >> >> Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h >> where available, and falls back to I64 on MSVC and then ll for others, >> all format warnings suppressed. > > JonY, > > Sorry for the delay on actually getting on to this. > > I tried your patch, but it wasn't quite right. The problem is that %ll > is th...

Hello, I'm trying to get to grips with the c interface of llvm intending to eventually develop a front end for Purebasic Though I've hit the wall already writing an iterative Fibonacci function. While I think the module dump looks ok it doesn't work for any input > 2 the function returns 2, the loop only executes once Hopefully someone can see what the problem is from the

The Open Group Single Unix standard shows that the data types int64 and uint64 are defined in the inttypes.h header file. Rsync is not including this file, nor is there a feature test for this header file in the configure phase, but rsync is using these data types. -John wb8tyw@qsl.net Personal Opinion Only

...format ‘%lld’ expects type ‘long long int’, but > argument > 2 has type ‘int64_t’ > $ gcc -Wall -O2 p.c -m32 > p.c: In function ‘main’: > p.c:6: warning: format ‘%ld’ expects type ‘long int’, but argument 2 > has > type ‘int64_t’ To print a int64_t value, use PRId64 from inttypes.h if you can. #include <inttypes.h> int64_t x = ...; printf("x=%"PRId64"\n", x); It's ugly at first, but portable (provided inttypes.h ...). Eric

...; #include <assert.h> #include <libintl.h> diff --git a/src/copy-in-out.c b/src/copy-in-out.c index e3697c0..fdc3f38 100644 --- a/src/copy-in-out.c +++ b/src/copy-in-out.c @@ -20,8 +20,6 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> -#include <inttypes.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> diff --git a/src/create.c b/src/create.c index d80939c..7f31bdb 100644 --- a/src/create.c +++ b/src/create.c @@ -39,7 +39,6 @@ #include "guestfs.h" #include "guestfs-internal.h" #inclu...

...functions (bitmath.h) If you include "share/compath.h" you will get a inline #defined as __inline when _MSC_VER is defined. I'd prefer a single diffinition of that in one place and one place only. > * change instances of uint32_t in bitwriter.c to FLAC__uint32 Can we include <inttypes.h> to fix this instead? > * functions marked inline cannot be used within another C file (e.g. > FLAC__bitreader_get_input_bits_unconsumed produces the linker error "error > LNK2001: unresolved external symbol > _FLAC__bitreader_get_input_bits_unconsumed"). This change ha...

...g.h:38: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?strlcpy? /mlsyslinux/com32/include/string.h:42: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?strspn? In file included from /mlsyslinux/com32/include/stdint.h:8, from /mlsyslinux/com32/include/inttypes.h:9, from /mlsyslinux/com32/libupload/cpio.c:9: /mlsyslinux/com32/include/bitsize/stdint.h:21:2: error: #error "Unable to build for to-be-defined architecture type" In file included from /mlsyslinux/com32/include/inttypes.h:9, from /mlsyslinux/com32/libup...

...1 - libinstaller/syslxmod.c | 1 - 3 files changed, 3 deletions(-) diff --git a/dos/getsetsl.c b/dos/getsetsl.c index 5260a2a..ba32b15 100644 --- a/dos/getsetsl.c +++ b/dos/getsetsl.c @@ -4,7 +4,6 @@ */ #define _XOPEN_SOURCE 500 /* Required on glibc 2.x */ -#define _BSD_SOURCE #include <inttypes.h> #include <string.h> #include <stddef.h> diff --git a/libinstaller/fs.c b/libinstaller/fs.c index 179629e..e5a854c 100644 --- a/libinstaller/fs.c +++ b/libinstaller/fs.c @@ -17,7 +17,6 @@ */ #define _XOPEN_SOURCE 500 /* Required on glibc 2.x */ -#define _BSD_SOURCE #include...

...ouble with PRIx64 and buddies in the X86 target on SLES 11. After searching, my issue seems like a generic problem with PRI support on different OS's. Here's a decent description of my problem: http://gcc.gnu.org/ml/gcc-help/2006-10/msg00221.html Any suggested methods to correct for <inttypes.h> not having the proper macros defined (besides defining the macros myself)? Has anyone else had trouble with these macros? Ty, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/d9398ed9/a...

.../string.h:15: warning: conflicting types for built-in function ?mempcpy? > /mlsyslinux/com32/include/string.h:16: error: expected declaration specifiers or ?...? before ?size_t? > In file included from /mlsyslinux/com32/include/stdint.h:8, > from /mlsyslinux/com32/include/inttypes.h:9, > from /mlsyslinux/com32/libupload/cpio.c:9: > /mlsyslinux/com32/include/bitsize/stdint.h:21:2: error: #error "Unable to build for to-be-defined architecture type" > In file included from /mlsyslinux/com32/include/inttypes.h:9, > from /ml...

...ented. ---------------------------------------------------------------------- I'm also not keen on the way that we use: #define UINT64 unsigned long long #define uint64_t unsigned long long These should (a) be the same (:-), (b) be typedefs, and (c) not be there anyway because #include <inttypes.h> will get them for us on modern systems. (If they aren't there, we can add configure checks - inttypes.h is in C99.) (If we used inttypes.h in quartz/flint, the uint4 typedef would be reliable, or actually just replaced by uint32_t.) J -- /----------------------------------------------...

...don't have the time or patience to maintain one. > > For windows stuff I'll be relying on others to provide and test > patches. > > Erik Alright, here's a quick fix, although it is more ugly than I remembered. Basically, it removes those _MSC_VER ifdefs, and relies on inttypes.h where available, and falls back to I64 on MSVC and then ll for others, all format warnings suppressed. Tested on MinGW. Sven-Hendrik, or any other mingw guys around, do you mind testing the patch too? Patch based on git master from https://git.xiph.org/mirrors/flac.git. -------------- next par...

...re: Ignore these files. * m4/codeset.m4: Remove file. * m4/gettext.m4: Likewise. * m4/glibc2.m4: Likewise. * m4/glibc21.m4: Likewise. * m4/iconv.m4: Likewise. * m4/intdiv0.m4: Likewise. * m4/intl.m4: Likewise. * m4/intldir.m4: Likewise. * m4/intlmacosx.m4: Likewise. * m4/intltool.m4: Likewise. * m4/inttypes-pri.m4: Likewise. * m4/inttypes.m4: Likewise. * m4/inttypes_h.m4: Likewise. * m4/isc-posix.m4: Likewise. * m4/lcmessage.m4: Likewise. * m4/lib-ld.m4: Likewise. * m4/lib-link.m4: Likewise. * m4/lib-prefix.m4: Likewise. * m4/lock.m4: Likewise. * m4/longdouble.m4: Likewise. * m4/longlong.m4: Likewise....

...generator/c.ml | 2 -- 1 file changed, 2 deletions(-) diff --git a/generator/c.ml b/generator/c.ml index 055b683..963cf21 100644 --- a/generator/c.ml +++ b/generator/c.ml @@ -1213,9 +1213,7 @@ and generate_client_actions hash () = #include <stdlib.h> #include <stdint.h> #include <inttypes.h> -#include <sys/types.h> #include <sys/stat.h> -#include <string.h> #include \"guestfs.h\" #include \"guestfs-internal.h\" -- 2.5.0

Otherwise, well, things tend not to pan out as they should when compiling anything that #includes md5.h Patch against cvs HEAD attached /dale -------------- next part -------------- Index: src/md5.h =================================================================== RCS file: /usr/local/cvsroot/icecast/src/md5.h,v retrieving revision 1.2 diff -u -r1.2 md5.h --- src/md5.h 29 Jan 2004 01:02:06

On Mar 9, 2004, at 12:33 PM, Ralph Giles wrote: > > Doesn't solaris also provide them in inttypes.h? maybe this would be > more appropriate (in > compat.h): You are correct, sir. Solaris does indeed have inttypes.h, which includes sys/inttypes.h, which then includes sys/int_types.h, which defines uint32_t :) The AC_HEADER_STDC macro already looks for inittypes.h, so all we needed to...