search for: baad

...achine (very unusual) or some of the parameters are > declared as "const". The problem is that the code generated by the C backend cannot include any system headers. If the system header were to have a #define (not a rare occurance) the header could arbitrarily change the CBE code in BAAD ways. :( There is no reason for GCC to emit this warning. Basically it is expecting slightly different, but compatible, types in the prototype. I don't think there is any clean way to work around this, but I'm certainly open to suggestions. :) -Chris > Reid. > > On Wed, 2004-...

On Wed, 2004-04-14 at 20:35, Chris Lattner wrote: > The problem is that the code generated by the C backend cannot include any > system headers. If the system header were to have a #define (not a rare > occurance) the header could arbitrarily change the CBE code in BAAD ways. > :( I was thinking of Eric doing something like: myfile.c: #include <string.h> #include "cbe_generated_file.c" Although, why he would eludes me. Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: applica...

...gt; On Wed, 2004-04-14 at 20:35, Chris Lattner wrote: > > > The problem is that the code generated by the C backend cannot include any > > system headers. If the system header were to have a #define (not a rare > > occurance) the header could arbitrarily change the CBE code in BAAD ways. > > :( > > I was thinking of Eric doing something like: > > myfile.c: > #include <string.h> > #include "cbe_generated_file.c" > > Although, why he would eludes me. You don't need to do this to get those annoying GCC warnings. They come...

The only thing I can think of is that string.h is being #included and has different signatures for memcpy and strncpy. Possibly "char" is not signed on your machine (very unusual) or some of the parameters are declared as "const". Reid. On Wed, 2004-04-14 at 18:19, Eric Zimmerman wrote: > Chris, > > I'm fine with using JIT, but I'm trying to understand this

How 'bout PAM? /usr/ports/security/pam_ldap. If you have machines that can't do PAM, perhaps NIS is the way to go (assuming, of course, you're behind a firewall). You can store login information in LDAP like you want, then use a home-grown script to extract the information to a NIS map. Or, if you have a Solaris 8 machine lying around, you can cut out the middle step and use

Here's the problem: > 2) Encoding with rate control as in single pass "Bitrate > control" will not > lead to better quality than fixed quant (with the right value > of the fixed > quant). Ratecontrol doens't know anything about "quality". It > will try to > reach more-or-less CBR. > > But somehow this is not a fair comparison, because

Chris, I'm fine with using JIT, but I'm trying to understand this problem: 1. My LLVM program does not produce correct results 2. Using llvm-dis, I disassemble the bytecode to C 3. I recompile using GCC and the program _works correctly_. The only odd thing is when I recompile with GCC, I see these messages: pal3.c:195: warning: conflicting types for built-in function `strcmp'