On Aug 11, 2008, at 1:13 PM, Jonathan S. Shapiro wrote:> Delayed reaction. Chris's response that the emitted code relies on > long > long to be a 64-bit type just sunk in. > > Chris: is there some reason why the backend does not #include > <stdint.h> > and then emit [u]int64_t (and the other sized types as well) and also > [u]intptr_t?The CBE output can't #include standard headers, the macros and types that are defined in the headers will conflict. -Chris
Le 11 août 08 à 22:29, Chris Lattner a écrit :> > On Aug 11, 2008, at 1:13 PM, Jonathan S. Shapiro wrote: > >> Delayed reaction. Chris's response that the emitted code relies on >> long >> long to be a 64-bit type just sunk in. >> >> Chris: is there some reason why the backend does not #include >> <stdint.h> >> and then emit [u]int64_t (and the other sized types as well) and also >> [u]intptr_t? > > The CBE output can't #include standard headers, the macros and types > that are defined in the headers will conflict. > > -ChrisNot to mention that this header is not present on all plateform, for example the one that use WORD and DWORD as common integer types does not provide a stdint file.
On Mon, 2008-08-11 at 13:29 -0700, Chris Lattner wrote:> The CBE output can't #include standard headers, the macros and types > that are defined in the headers will conflict.Is that true for the freestanding header files? We have not found it so in the C backend for BitC, though admittedly it was a design objective to avoid exactly these conflicts. I would think, in particular, that stdint.h and inttypes.h would both be safe. shap
On Aug 11, 2008, at 1:40 PM, Jonathan S. Shapiro wrote:> On Mon, 2008-08-11 at 13:29 -0700, Chris Lattner wrote: >> The CBE output can't #include standard headers, the macros and types >> that are defined in the headers will conflict. > > Is that true for the freestanding header files?Yes. The only exceptions to the rule have been alloca.h, setjmp.h and stdarg.h, and even those have been a huge pain and we avoid them on platforms where we can. One example problem is that llvm doesn't preserve signedness of types, so you end up with a header defining: void foo(int); and the CBE emits a prototype of: void foo(unsigned); which leads to compilation failures. -Chris
On Mon, 2008-08-11 at 22:39 +0200, Jean-Daniel Dupas wrote:> Not to mention that [stdint.h] is not present on all plateform, for > example the one that use WORD and DWORD as common integer types does > not provide a stdint file.9 years later and they still aren't C99 compliant? Gack. Regardless, my main point was that using descriptive type names might be a good thing. I'm not stuck on stdint.h as the particular solution.