similar to: Circular preprocessor define with MSVC

Hello, I was trying to compile Flac on MinGW/Msys but got an error stating SIZE_T_MAX is undefined. To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and made the following change: Starting at line #36 I changed: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX UINT_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX

Hi, I went in big trouble compiling Flac (Windows). With configure (msys and mingw32-make 4.5.2) I didn't have success to compile. Makefile.lite the same. I used also the patches for SIZE_T_MAX UINT_MAX . Then I could compile every (!) project in flac with MSVC 2008 and I got all libraries, *.dll and *.exe. The libraries are passing all test-programs. With my own tools I see the *.dlls

will surgent wrote: > Hello, I was trying to compile Flac on MinGW/Msys but got an error stating > SIZE_T_MAX is undefined. > To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and > made the following change: <snip> > #ifndef SIZE_MAX > # ifndef SIZE_T_MAX > # ifdef _MSC_VER > # define SIZE_T_MAX UINT_MAX > # elif

http://bugzilla.mindrot.org/show_bug.cgi?id=458 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|IRIX |All Platform|MIPS |All ------- Additional Comments From dtucker at zip.com.au 2003-09-05 14:23

Not sure about any other version, but I know sol7 lacks SIZE_T_MAX which we are now using in -current. OpenBSD defines it as ULONG_MAX. Pawing through the Solaris /usr/include it stated it could be 'u_int' or 'u_long'. Depends on if your are compiling legacy stuff. I'm sure other OSes may encounter this issue (not tried Linux, but Redhat 7.x does not define it), but what

Hi all, The following patch fixes cross compiling from Linux to windows. The existing code was doing: #if !defined _MSC_VER && !defined __MINGW32__ && !defined __EMX__ #include <stdint.h> /* for SIZE_MAX in case limits.h didn't get it */ #endif when it seems to make much more sense to just test for the presence of <stdint.h> and do: #ifdef

I've been putting some work into building Libflac into a game engine I'm working on. I ran into a few small issues in the process, and was able to fix them, so I thought I'd post with my fixes. These aren't generally applicable - I'm taking a "shortest path to functionality" approach - but with a little work could probably be turned into general patches. First,

On 13 July 2016 at 10:19, Luis de Bethencourt <luisbg at osg.samsung.com> wrote: > On 11/07/16 23:46, Markus Mayer wrote: > > Hi Markus, > > Amazing. I see this happening as well, but I know it shouldn't. > > The reason the #ifndef guards in headers are there is precisely to allow > circular dependencies. > > The problem in your output reads as: >

On Aug 2, 2011, at 8:53 AM, Duncan Sands wrote: > Hi Eli, > >>>> Icmp sgt is correct. >>> >>> while ugt would be wrong, I think sgt is too! >>> >>> For example, suppose %buf is 0 and %bufLen is ~0U. Then %add.ptr is ~0U, and >>> %cmp is true, so control branches to %if.then. However in the optimized version >>> %cmp is

Hello, We use two different patches to build flac. The first one is a patch that detects correctly ranlib, ac, strip when you cross-compile. We especially use the patch when compiling for Windows under GNU/Linux. http://trac.videolan.org/vlc/browser/trunk/extras/contrib/src/Patches/flac-cross.patch The other one fixes an issue when compiling for Windows under Cygwin, that can't find

Erik de Castro Lopo wrote: > will surgent wrote: > > > Hello, I was trying to compile Flac on MinGW/Msys but got an error stating > > SIZE_T_MAX is undefined. > > To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and > > made the following change: Would it be possible to get this patch applied? I still hit this every time I try to

http://bugzilla.mindrot.org/show_bug.cgi?id=458 ------- Additional Comments From us- at gmx.de 2002-12-19 03:16 ------- Sorry, typo: The irix version is 6.5.17 not 6.5.18 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication could overflow and the access_ok() check wouldn't test the right size. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 215a3c0..fdff8f9 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c

If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication could overflow and the access_ok() check wouldn't test the right size. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 215a3c0..fdff8f9 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c

On 2016-05-20 19:58, David Majnemer via llvm-dev wrote: > I've come across this issue before and came to the following conclusion: > - We are not obligated to support objects that large, C11 5.2.4.1/1 only > requires that we support objects of size 65535! Right, the standard doesn't require it. But I guess you don't imply that it's fine for clang to silently miscompile

Both split ring and packed ring use 32bits to describe the length of a descriptor: see struct vring_desc and struct vring_packed_desc. This means the max segment size supported by virtio is U32_MAX. An example of virtio_max_dma_size in virtio_blk.c: u32 v, max_size; max_size = virtio_max_dma_size(vdev); -> implicit convert err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX,

On 9 July 2016 at 08:30, Markus Mayer <markus.mayer at broadcom.com> wrote: > On 9 July 2016 at 05:04, Luis de Bethencourt <luisbg at osg.samsung.com> wrote: >> On 08/07/16 23:43, Markus Mayer wrote: >>> Add a collection of generic functions to convert strings to lowercase >>> or uppercase. >>> >>> Changing the case of a string (with or

Fixes after recent use of kvmalloc Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- tools/virtio/ringtest/ptr_ring.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/virtio/ringtest/ptr_ring.c b/tools/virtio/ringtest/ptr_ring.c index 477899c..2d566fb 100644 --- a/tools/virtio/ringtest/ptr_ring.c +++ b/tools/virtio/ringtest/ptr_ring.c @@ -17,6 +17,8 @@ #define

On 08/07/16 23:43, Markus Mayer wrote: > Add a collection of generic functions to convert strings to lowercase > or uppercase. > > Changing the case of a string (with or without copying it first) seems > to be a recurring requirement in the kernel that is currently being > solved by several duplicated implementations doing the same thing. This > change aims at reducing this

On Wed, 10 May 2023 10:54:37 +0800, zhenwei pi <pizhenwei at bytedance.com> wrote: > Both split ring and packed ring use 32bits to describe the length of > a descriptor: see struct vring_desc and struct vring_packed_desc. > This means the max segment size supported by virtio is U32_MAX. > > An example of virtio_max_dma_size in virtio_blk.c: > u32 v, max_size; > >