search for: stdint

Hi, Just to clarify, some header files are compiler specific. Stdint.h is one of them. The reason your Ubuntu stdint.h works is because, coincidentally, Clang's stdint.h uses the same layout and pre-processor built-ins as GCC. This is an implementation detail. Do not rely upon it. You should use Clang's stdint.h. Cheers, James From: Seung-yeon Choe [mailt...

Hello, James Molly. Thank you for your advices. Now I aware that this is the problem of stdint.h. And, codesourcery toolchain also has stdint.h header file at same place of stdio.h Generally, Clang has "lib/clang/3.0/include" default search path. If I added codesourcery toolchain path for stdio.h with -I option, stdint.h has been loaded at the specified toolchain path first cuz cl...

Hi, There is a little bit awkward thing. If I need to use the newlibc printf function regardless stdint.h is compiler specific implementation, I should remove or block newlibc's stdint.h and the others because as you know clang already stdint.h (glibc compatible??) header but it is not standard library full set, right? On the other hand, even if I want to use other toolchain's glibc function...

...>> --- a/include/llvm/System/DataTypes.h.cmake >>>> +++ b/include/llvm/System/DataTypes.h.cmake >>>> @@ -100,6 +100,9 @@ typedef u_int64_t uint64_t; >>>>  #else >>>>  #include <math.h> >>>>  #endif >>>> +#ifdef HAVE_STDINT_H >>>> +#include <stdint.h> >>>> +#else /* !HAVE_STDINT_H */ >>> >>> This looks incorrect to me. stdint.h is already included below for >>> non-MSVC systems. Maybe you inteded to #include it for MSVC only? Or do >>> intend to correct...

...newlibc. but, arm gnu/linux version uses glibc. hm.. actually there is no problem. it was my mistake as james told me. Thanks. 2011/11/24 Seung-yeon Choe <sychoe at gmail.com> > Hello, James Molly. > > Thank you for your advices. > > Now I aware that this is the problem of stdint.h. And, codesourcery > toolchain also has stdint.h header file at same place of stdio.h > > Generally, Clang has "lib/clang/3.0/include" default search path. > If I added codesourcery toolchain path for stdio.h with -I option, > stdint.h has been loaded at the specified too...

...llow-to-build-against-static-MSVC-runtime.patch Type: text/x-patch Size: 2055 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100306/69a65259/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Include-stdint.h-when-HAVE_STDINT_H-is-defined-on-MS.patch Type: text/x-patch Size: 1244 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100306/69a65259/attachment-0001.bin>

Dear all. I built the LLVM 3.0 rc4 with Clang front-end in windows os env. (also with -DLLVM_TARGETS_TO_BUILD=all option) For arm neon intrinsics testing, I tried to compile some codes, which are included a few neon intrinsics. Although I got a well done bitcode on ubuntu build pc, it shows some errors when compile the codes on windows. Could you let me know why occurred errors? is this just a

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".

...clang/3.3/include/llvm/ADT/StringRef.h:13, from /usr/clang/3.3/include/llvm/ADT/Twine.h:13, from /usr/clang/3.3/include/llvm/ADT/Triple.h:13, from /home/drlou/Downloads/dragonegg-3.3.src/utils/TargetInfo.cpp:23: /usr/clang/3.3/lib/clang/3.3/include/stdint.h:32:54: error: missing binary operator before token "(" /usr/clang/3.3/lib/clang/3.3/include/stdint.h:187:0: warning: "__int_least32_t" redefined [enabled by default] /usr/clang/3.3/lib/clang/3.3/include/stdint.h:113:0: note: this is the location of the previous definition /usr...

Hi! VS2010 now includes a stdint.h header. LLVM assumes that there is no stdint.h header and creates own types and macros. Because the macros in the stdint.h header are not protected, you get warnings at compile time if you first include llvm/Support/Datatypes.h and then stdint.h. The attached patch includes stdint.h depending...

Erik de Castro Lopo wrote: >> because MSVS2005 doesn't provide stdint.h. According to MSDN, >> uintptr_t is defined in "STDDEF.H and other include files". > > Does the rest of FLAC actually support those compilers? Yes. I removed this #include and all projects were successfully built with MSVS 2005 Express. > Is it worth > continuing to...

...)threads. OpenBSD 3.1 isn't officially released, yet, but installing a current snapshot and getting the sources via CVS (module OPENBSD_3_1_BASE, patient people also can already upgrade from scratch only with the sources) worked for me. Compiling libshout failed because src/mp3.c included <stdint.h> which appears to be missing on OBSD3.1. Using a friend's stdint.h and seeing it fail again showed that machine/types.h equals stdint.h here. `ln -s /usr/include/machine/types.h /usr/include/stdint.h` fixed that. I have no clue why stdint.h wasn't there in the first place - either this...

Hi, I was recently pointed out that a definition in Rinterface.h can be conflicting with a definition in stdint.h: /usr/include/R/Rinterface.h has: typedef unsigned long uintptr_t; /usr/include/stdint.h has: typedef unsigned int uintptr_t; (when 32bit platform complete definition is: #if __WORDSIZE == 64 # ifndef __intptr_t_defined typedef long int intptr_t; # define __intptr_t_defined...

Hi together, here is a little success tory how I got flac 1.2.1 (ZIP from downloads page) compiled with Solaris 7: First of all you need a lot packages from sunfreeware.com If you have installed the required packages you may end up with an error that says there is no stdint.h on your system. On an other forum I have read upgrading to Solaris 10 "fixes" this problem but that might not being an option to many people for their different reasons. Well, I just rewrote include/share/alloc.h, line 32 from stdint.h to inttypes.h and it fixes! Maybe you can try it...

Chris Lattner wrote: >>ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and >>InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes >>from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, >>but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at >>least in CSIL) unfortunately does not have stdint.h, but it does have >>the old inttypes.h - and so does Linux. >> >> > >Interesting. INT64_MAX is supposed to be provided by >inclu...

ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at least in CSIL) unfortunately does not have stdint.h, but it does have the old inttypes.h - and so does Linux. ACTION: In files that refer to INT64_MAX, ensure that inttypes.h is #included and that __STD_LIMIT_MACROS is #def...

...nstead of /MD, so replacing /MD with /MTd, for instance, would give /MTdd) > --- a/include/llvm/System/DataTypes.h.cmake > +++ b/include/llvm/System/DataTypes.h.cmake > @@ -100,6 +100,9 @@ typedef u_int64_t uint64_t; > #else > #include <math.h> > #endif > +#ifdef HAVE_STDINT_H > +#include <stdint.h> > +#else /* !HAVE_STDINT_H */ This looks incorrect to me. stdint.h is already included below for non-MSVC systems. Maybe you inteded to #include it for MSVC only? Or do intend to correct some problem with non-MSVC builds too? > typedef __int64 int64_t; &gt...

From: Tanu Kaskinen <tanu.kaskinen at linux.intel.com> Not everyone who includes speexdsp_config_types.h will have a test which defines those, and if we've chosen to use the stdint types at configure time then we know exactly which header(s) are available, so just choose the best one then and generate the header to use it. This patch, including the above text, is copied from a commit in the speex repository[1]. The original commit for speex was made by Ron <ron at debian....

stubdom: int32_t is provided by stdint.h, not sys/types.h diff -r c2472ded5c7c extras/mini-os/include/posix/dirent.h --- a/extras/mini-os/include/posix/dirent.h Tue Aug 26 15:16:57 2008 +0100 +++ b/extras/mini-os/include/posix/dirent.h Tue Aug 26 16:43:27 2008 +0100 @@ -1,7 +1,7 @@ #ifndef _POSIX_DIRENT_H #define _POSIX_DIRENT_H -#...

On Mon, 23 Feb 2015, Tom G. Christensen wrote: > On 19/02/15 23:21, Damien Miller wrote: > > Snapshot releases for portable OpenSSH are available from > > http://www.mindrot.org/openssh_snap/ > > > > I tried building openssh-SNAP-20150224.tar.gz on Solaris 2.6, 7, 8 and 9. > All failed because they do not have <sys/queue.h>. > Here's how it looks on