search for: cstdio

On Thu, 16 Aug 2007, David Greene wrote: > Actually, there's another reason not to use unlocked calls. They require > POSIX compliance. Posix is pretty available, what system doesn't have them? > To get portability and most of the performance I plan to look at unbuffered > stdio. Buffering is goodness, no? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...another reason not to use unlocked calls. They require > > POSIX compliance. > > Posix is pretty available, what system doesn't have them? Windows, for one. If POSIX is ok, it's better in my mind to just directly use open, write and friends, which is what I do now. Going the cstdio route should only be done for portability reasons to support non-POSIX systems. > > To get portability and most of the performance I plan to look at > > unbuffered stdio. > > Buffering is goodness, no? Buffering is goodness. The problem with using buffered cstdio under iostream...

...ncluded from /usr/include/c++/3.3/i486-linux/bits/c++io.h:35, from /usr/include/c++/3.3/bits/fpos.h:44, from /usr/include/c++/3.3/bits/char_traits.h:46, from /usr/include/c++/3.3/string:47, from wndclass.cxx:2: /usr/include/c++/3.3/cstdio:167: error: `snprintf' not declared /usr/include/c++/3.3/cstdio:168: error: `vfscanf' not declared /usr/include/c++/3.3/cstdio:169: error: `vscanf' not declared /usr/include/c++/3.3/cstdio:171: error: `vsscanf' not declared /usr/include/c++/3.3/cstdio:177: error: `snprintf' not...

On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > (can't imagine it won't work). We prefer #include <cstdio>, since this is C++ after all. :) -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

Here's the patch to Signals.cpp. assuming that stdio.h is acceptable (can't imagine it won't work). On Fri, 24 Sep 2004 09:29:05 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > Uh... this may be a silly question, but why can't you include <stdio.h>? > It'd be much better than <iostream>. > > Anyway, I think I'll try this weekend to come

...1.11 instead of a windows installation that I keep on a VM. I used 'winemaker ./' and then 'make' and that's what I got: Code: szczerb at nomad ~/projekty/wine/plansza $ make wineg++ -c -mno-cygwin -I. -o main.o main.cpp /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/cstdio:170: error: ::snprintf has not been declared /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/cstdio:171: error: ::vfscanf has not been declared /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/cstdio:172: error: ::vscanf has not been declared /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/includ...

...004 12:06:36 -0500 Misha Brukman <brukman at uiuc.edu> wrote: > On Fri, Sep 24, 2004 at 09:38:44AM -0700, Jeff Cohen wrote: > > Here's the patch to Signals.cpp. assuming that stdio.h is acceptable > > (can't imagine it won't work). > > We prefer #include <cstdio>, since this is C++ after all. :) > > -- > Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs....

...uniq -c > 1 #include <algorithm> > 10 #include <atomic> > 1 #include <bitset> > 6 #include <cassert> > 1 #include <cerrno> > 1 #include <cstddef> > 7 #include <cstdint> > 2 #include <cstdio> > 1 #include <cstdlib> > 2 #include <cstring> > 1 #include <deque> > 2 #include <iterator> > 2 #include <limits> > 2 #include <memory> > 4 #include <mutex> > 1 #include <system_e...

Someone needs to adjudicate on whether I add the #include of <cstdio> or not. I can't test this so, Paolo/Henrik/Jeff, please let me know if I need to add it. Thanks, Reid. On Fri, 2004-09-24 at 07:08, Jeff Cohen wrote: > But I compiled that under vc7.1 as it was! > > On Fri, 24 Sep 2004 15:19:22 +0200 > Paolo Invernizzi <arathorn at fastwe...

...llvm/Constants.h" #include "llvm/Function.h" #include "llvm/BasicBlock.h" #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/GenericValue.h" #include "llvm/Support/IRBuilder.h" #include <vector> #include <cstdio> #include <string> int main() { llvm::LLVMContext & context = llvm::getGlobalContext(); llvm::Module *module = new llvm::Module("asdf", context); llvm::IRBuilder<> builder(context); llvm::Value *helloWorld = builder.CreateGlobalStringPtr("hello world!\n&qu...

...sn't a choice. I have to research the issue > myself to see if it's possible to avoid using STLPort. > > > On Fri, 24 Sep 2004 07:42:51 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > Someone needs to adjudicate on whether I add the #include of <cstdio> or > > not. I can't test this so, Paolo/Henrik/Jeff, please let me know if I > > need to add it. > > > > Thanks, > > > > Reid. > > > > On Fri, 2004-09-24 at 07:08, Jeff Cohen wrote: > > > But I compiled that under vc7.1 as it was!...

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

On Fri, 17 Aug 2007, David Greene wrote: >> Posix is pretty available, what system doesn't have them? > > Windows, for one. If POSIX is ok, it's better in my mind to just directly Windows has POSIX calls. > use open, write and friends, which is what I do now. Going the cstdio > route should only be done for portability reasons to support non-POSIX > systems. I don't think open/write etc are POSIX. Windows has them but you have to use different headers etc to get access to them. I am no expert in this area though. >>> To get portability and most...

Following simple program gives different answers when compiling with GCC (4.8.4) and ToT Clang: $ cat builtin_fmodf_bugpoint.cpp #include <cstdio> int main(int argc, char** argv) { const float a = 1.0f; const float b = 0.1f; printf("%f mod %f = %f\n", a, b, __builtin_fmodf(a, b)); return 0; } $ g++ -o builtin_fmodf_bugpoint_gcc builtin_fmodf_bugpoint.cpp $ ./builtin_fmodf_bugpoint_gcc 1.000000 fmodf 0.100000 = 0.100000...

...ithout STLPort, then there really isn't a choice. I have to research the issue myself to see if it's possible to avoid using STLPort. On Fri, 24 Sep 2004 07:42:51 -0700 Reid Spencer <reid at x10sys.com> wrote: > Someone needs to adjudicate on whether I add the #include of <cstdio> or > not. I can't test this so, Paolo/Henrik/Jeff, please let me know if I > need to add it. > > Thanks, > > Reid. > > On Fri, 2004-09-24 at 07:08, Jeff Cohen wrote: > > But I compiled that under vc7.1 as it was! > > > > On Fri, 24 Sep 2004 15:1...

...detailed explanation for their opinion, which I think is correct. See this link for the full story: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61015 The following program demonstrates the bug using LLVM's own ArrayRef: #define __STDC_LIMIT_MACROS #define __STDC_CONSTANT_MACROS #include <cstdio> #include <llvm/ADT/ArrayRef.h> class Obj {}; class SpecialObj : public Obj {}; int main() { SpecialObj* pSpecial = new SpecialObj(); llvm::ArrayRef<Obj*> arrayRef( pSpecial ); //Breaks on GCC-4.8. /* Obj* pObj = pSpecial; llvm::ArrayRef<Obj*> arrayRef( pObj ); //Po...

...8:48 -0000 1.13 +++ lib/Transforms/Scalar/LoopUnroll.cpp 19 Nov 2004 04:17:08 -0000 @@ -28,6 +28,7 @@ #include "llvm/Support/Debug.h" #include "llvm/ADT/Statistic.h" #include "llvm/ADT/STLExtras.h" +#include "llvm/IntrinsicInst.h" #include <cstdio> #include <set> #include <algorithm> @@ -86,6 +87,11 @@ // Ignore PHI nodes in the header. } else if (I->hasOneUse() && I->use_back() == Term) { // Ignore instructions only used by the loop terminator. + } else if (DbgStopPointInst *SPI =...

The solution (provided in Microsoft's documentation) is to add: #include <cstdio> #include <io.h> #include <fcntl.h> and run: int result = _setmode( _fileno(stdin), _O_BINARY ); if( result == -1 ) { std::cerr<<"Cannot set input mode to binary."<<std::endl; return 1; } result = _setmode( _fileno(stdout), _O_BINARY ); if( result == -...

...ch. So the only thing to > do was > to push a catch-all on to the end of the list. OK, playing around with the testsuite it appears there's a bug in llvm's inliner with EH, which is probably what's causing the effect you're talking about. Suppose we have #include <cstdio> class A { public: A() {} ~A() {} }; void f() { A a; throw 5.0; } main() { try { f(); } catch(...) { printf("caught\n"); } } The IR for f correctly has the throw call reaching the landing pad, which cleans up 'a' and then calls Unwind_Resume. Inlinin...

...t;> issue >> myself to see if it's possible to avoid using STLPort. >> >> >> On Fri, 24 Sep 2004 07:42:51 -0700 >> Reid Spencer <reid at x10sys.com> wrote: >> >>> Someone needs to adjudicate on whether I add the #include of >>> <cstdio> or >>> not. I can't test this so, Paolo/Henrik/Jeff, please let me know if I >>> need to add it. >>> >>> Thanks, >>> >>> Reid. >>> >>> On Fri, 2004-09-24 at 07:08, Jeff Cohen wrote: >>>> But I compiled that...