search for: nonportability

Hey, I ran across this while building vorbis on the Mac: In libvorbis RC2, file info.c, line 65, there's a call to strdup(). strdup() isn't portable, and it looks like the code should use the internal memory functions to create the memory for the string anyway. Actually, on further inspection, it looks like the memory for the user comments is never actually freed. I'm not subscribed

Hi folks, I'd like to remind people with write access on the CVS mainline not to put any tools/libs/patches into the main build that are not portable... I'm getting not-very-pretty flames from NetBSD folks because libao fails to *configure* under NetBSD (let alone build), thus breaking building the build for the entire CVS mainline. Specifically: >checking size of int...

On Jun 9, 2009, at 10:02 AMPDT, Paul Schlie wrote: >> Dale Johannesen wrote: >>> Marius Wachtler wrote: >>> ... >>> The call to address 0 gets removed. >>> >>> define i32 @t(i32 %a) noreturn nounwind readnone { >>> entry: >>> unreachable >>> } >>> >>> How can I prevent that the call is removed,

> Dale Johannesen wrote: >> Marius Wachtler wrote: >> ... >> The call to address 0 gets removed. >> >> define i32 @t(i32 %a) noreturn nounwind readnone { >> entry: >> unreachable >> } >> >> How can I prevent that the call is removed, without making the >> function addr volatile? >> Does anyone know which optimization

...; va_list arg; va_start(arg, format); vsnprintf(buf, BUFSIZE, format, arg); va_end(arg); buf[BUFSIZE - 1] = '\0'; error(buf); } ----- end code snippet ----- But that's not portable because vsnprintf isn't. You've already made a big effort to work around nonportability of vsnprintf, but don't make it available in the API. Why not? If I could change vsnprintf to Rvsnprintf above, then I wouldn't have to do some horrible autoconf song and dance that probably wouldn't be completely portable anyway. Or is there a better solution I haven't seen? --...

The installed Xen header files (/usr/include/xen/*) expect the U8, u16, u32, etc types to already be defined. Currently, xc.h provides this in a nonportable way. I''ve changed xc.h to use stdint.h, and fixed a few printf-style format strings to match. Thanks, Charles

New in flute directory. Telemann Methodical Sonatas > 1hour duration. I want arelatively cheap laptop to do portable recording. Any good choices available? .......Al --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word

On Fri, Oct 31, 2008 at 10:38:50AM -0700, Mike Stump wrote: > On Oct 31, 2008, at 9:40 AM, Jack Howarth wrote: >> However in current llvm svn, when I compile code with llvm-gfortran, I >> get these warning >> flags passed by default so that I get bogus warnings of... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/ >>

Hi all, I've noticed that OpenSSH 7.7 adds stricter validation of user environment strings from authorized_keys files. While strict validation is a good thing from a security perspective, this new change specifically blocks underscores which are common to include in a user environment string. This results in the key being rejected outright. Including underscores in a user environment is a

It is setting TZ and using tzset(). R is not multi-threaded so it is safe. Simon figure out the important settings from the config.log and config.h files on a musl system: /* #undef USE_INTERNAL_MKTIME */ #define HAVE_TM_GMTOFF 1 #define HAVE_TM_ZONE 1 Does this help anyone debug the issue? Simon just went on vacation. On Thu, Feb 4, 2016 at 7:32 PM, Rich Felker <dalias at libc.org>

On Thu, Sep 18, 2014 at 11:54 AM, Niels Ferguson <niels at microsoft.com> wrote: > Defining a standard way of transferring random numbers between the host and the guest is an excellent idea. > > As the person who writes the RNG code in Windows, I have a few comments: > > DETECTION: > It should be possible to detect this feature through CPUID or similar mechanism. That

Defining a standard way of transferring random numbers between the host and the guest is an excellent idea. As the person who writes the RNG code in Windows, I have a few comments: DETECTION: It should be possible to detect this feature through CPUID or similar mechanism. That allows the code that uses this feature to be written without needing the ability to catch CPU exceptions. I could be

Defining a standard way of transferring random numbers between the host and the guest is an excellent idea. As the person who writes the RNG code in Windows, I have a few comments: DETECTION: It should be possible to detect this feature through CPUID or similar mechanism. That allows the code that uses this feature to be written without needing the ability to catch CPU exceptions. I could be

On Fri, 17 Sep 2004, Andrew Lenharth wrote: > > Hrm, I would much rather just have LLVM be a drop in replacement for a C > > compiler. As such, it should expose identical #defines to GCC. > > A drop in replacement for "a C compiler" is rather a different > requirement than a drop in replacement for GCC. If the goal is pure GCC > compatibility then sure,

Hi, I'd like to propose that we introduce a mechanism in LLVM for declaring that the symbol for a given global variable should be assembled at a given offset from the start of the data for that global. The main reason for doing this would be to allow a module to conform to an externally imposed ABI which requires data to be present below a symbol. We have two specific use cases in mind at

The chief advantage I see to using a hypercall based mechanism is that it would work across more architectures. MSR's and CPUID's are specific to X86. If we ever wanted this same mechanism to be available on an architecture that doesn't support MSR's, a hypercall based approach would allow for a more consistent mechanism across the architectures. I agree, though, that

The chief advantage I see to using a hypercall based mechanism is that it would work across more architectures. MSR's and CPUID's are specific to X86. If we ever wanted this same mechanism to be available on an architecture that doesn't support MSR's, a hypercall based approach would allow for a more consistent mechanism across the architectures. I agree, though, that

Hello, You know, I always worry about the precision and the float constants... and there is a large lookup table in the floor1.c ... and I figure out a way to keep the code size and speed, but to improve the precision at this lookup table. (the difference is small, but audible) Here is the modifications in the floor1.c: tatic unsigned long FLOOR_fromdB_LOOKUP[256]={

> Dale Johannesen wrote: >> Paul Schlie wrote: >>> Dale Johannesen wrote: >>>> Marius Wachtler wrote: >>>> ... >>>> The call to address 0 gets removed. >>>> >>>> define i32 @t(i32 %a) noreturn nounwind readnone { >>>> entry: >>>> unreachable >>>> } >>>>

On Thu, 2004-09-16 at 23:45, Chris Lattner wrote: > On Thu, 16 Sep 2004, Andrew Lenharth wrote: > > So I propose that llvm-gcc not consider itself any type of x86-linux (or > > what ever it platform it was compiled on), but rather create a new > > architecture, say llvm (or perhaps 2, one for each bit and little > > endian). Thuse llvm-gcc -dumpmachine would return