search for: ptrdiff_t

Hi all-- I tried building the ARM-optimized theora codec from the theorarm- merge-branch, and encountered the following compile and runtime problems before getting something to run. If there is another way to build it, it would be nice to know, but I got the sense that its current state in svn is incomplete. I'm using a gcc cross-compiler for ARM on an x86 Linux PC. After running

...le code works just fine: struct A { int ai; }; struct X : virtual A { int xi; }; struct Y : virtual A { int yi; }; struct S : X, Y { string a; string b; }; template<class ClassType,class MbrType> inline ptrdiff_t mbr_offset_of( MbrType ClassType::*p ) { ClassType const *const c = static_cast<ClassType*>( nullptr ); return reinterpret_cast<ptrdiff_t>( &(c->*p) ); } int main() { ptrdiff_t offset = mbr_offset_of( &S::b ); S s;...

...| 8 > 32 bit windows | 4 | 4 > 64 bit windows | 4 | 4 > > Note that sizeof(long) on 64 bit windows is 4! > > Most other unixen follow the LP64 scheme used by Linux. > > Erik On Windows x64 sizeof(long) is 4, but sizeof(ptrdiff_t) is 8. Any reasons for not using sizeof(ptrdiff_t)? Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20151231/751f92da/attachment.htm

...uot; wrapper to call it. However, assume that there is no such S member function. I therefore need a way to get the offset of 'b' and add it to 's' so that I can call T_string_M_assign_Pv() on it. Given this helper function: template<class ClassType,class MbrType> inline ptrdiff_t mbr_offset_of( MbrType ClassType::*p ) { ClassType const *const c = static_cast<ClassType*>( nullptr ); return reinterpret_cast<ptrdiff_t>( &(c->*p) ); } I could take a Pointer to an S, use ptrtoint, add the offset, use inttoptr, and use that pointer to pass as the 't...

...{ int ai; }; > struct X : virtual A { int xi; }; > struct Y : virtual A { int yi; }; > > struct S : X, Y { > string a; > string b; > }; > > template<class ClassType,class MbrType> inline > ptrdiff_t mbr_offset_of( MbrType ClassType::*p ) { > ClassType const *const c = static_cast<ClassType*>( nullptr ); > return reinterpret_cast<ptrdiff_t>( &(c->*p) ); > } > > int main() { > ptrdiff_t offset = mbr_offset_of( &am...

...struct X : virtual A { int xi; }; >> struct Y : virtual A { int yi; }; >> >> struct S : X, Y { >> string a; >> string b; >> }; >> >> template<class ClassType,class MbrType> inline >> ptrdiff_t mbr_offset_of( MbrType ClassType::*p ) { >> ClassType const *const c = static_cast<ClassType*>( nullptr ); >> return reinterpret_cast<ptrdiff_t>( &(c->*p) ); >> } >> >> int main() { >> ptrdiff_t offset...

...sume that there is no such S member function. I therefore need a way to get the offset of 'b' and add it to 's' so that I can call T_string_M_assign_Pv() on it. > > Given this helper function: > > template<class ClassType,class MbrType> inline > ptrdiff_t mbr_offset_of( MbrType ClassType::*p ) { > ClassType const *const c = static_cast<ClassType*>( nullptr ); > return reinterpret_cast<ptrdiff_t>( &(c->*p) ); > } > > I could take a Pointer to an S, use ptrtoint, add the offset, use inttopt...

This patch protects against redefinitions of size_t. There are currently at least two different definitions provided with klibc: unistd.h -> stddef.h -> bits32/bitsize/stddef.h sys/times.h -> linux/times.h -> linux/types.h both define size_t, causing gcc to complain. I suspect ptrdiff_t has a similar problem; not covered by this patch. Regards, Erik diff -urN klibc-0.202-pristine/include/bits32/bitsize/stddef.h klibc-0.202/include/bits32/bitsize/stddef.h --- klibc-0.202-pristine/include/bits32/bitsize/stddef.h 2004-07-07 02:41:04.000000000 +0200 +++ klibc-0.202/include/bits32/bi...

...libstdc++ / glibc compatibility issues people have been having with 3.4: r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER is defined) r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, wint_t}. The changes look safe to merge but I'd like to hear a second opinion from Chandler or Nico. Alp. -- http://www.nuanti.com the browser experts

Hi All, In this session we would like to talk about SPIR size_t/ptrdiff_t approach and get feedback about it. Guy has prepared a patch that demonstrates some of the changes in Clang and we hope to have a good discussion based on it. In addition, we are interested in meeting others who care about the concept of SPIR and would like to learn more about their usages. Cheer...

VS has a 64-bit portability mode, where it will complain when it sees non-portable code. I haven't tried it yet on LLVM, but in my experience it will generate a *lot* of warnings. Every time a size_t or ptrdiff_t is assigned to an int or even a long it will complain (Microsoft defines long as 32-bits, even in win64). On the other hand, gcc defines long as 64-bits on 64-bit Unix (so what does it do on cygwin or mingw?). The portability warnings are still useful, but it does mean that "long" m...

...e add this, definitely, with high urgency (as klibc?s dash is also affected), until *all* architectures are switched to RT signals. There?s another, new, patch (0004 here), based on a request by hpa: http://www.zytor.com/pipermail/klibc/2012-April/003199.html It changes the way size_t, ssize_t and ptrdiff_t are defined to use the definition from the compiler (GCC and compatibles, such as Clang) with a fallback to long/unsigned long if none is given, which is always correct on LP64 and by-the-size correct on ILP32 platforms. This is mostly for benefit of GCC?s -Wformat so the fallback not being int/uns...

We have code that processes a buffer in the forward or backwards direction. It looks similar to the following (https://github.com/weidai11/cryptopp/blob/master/adv-simd.h#L1138): uint8_t * ptr = ... size_t len = ... size_t inc = 16; if (flags & REVERSE_DIRECTION) { ptr += len - inc; inc = 0-inc; } while (len > 16) { // process blocks ptr += inc; len -= 16; } Clang

Hi, I wanted to ask if people have good advice on how to debug M1Mac package check errors when you don?t have a Mac? Is a cloud machine the best option or is there something else? Thanks Holger [[alternative HTML version deleted]]

...t D.2717; long int p.1; long int q.0; int D.2714; <bb 2>: q.0_2 = (long int) q_1(D); p.1_4 = (long int) p_3(D); D.2717_5 = q.0_2 - p.1_4; D.2718_6 = D.2717_5 /[ex] 4; D.2714_7 = (int) D.2718_6; return D.2714_7; } Signed overflow in the difference of two long int (ptrdiff_t) values results in undefined behaviour according to the GCC type system, which is where the nsw flag comes from. The C front-end generates this gimple in the pointer_diff routine. The above is basically a direct transcription of what pointer_diff does. In short, I don't know if this is right...

...declares the function as returning an i8*. Perhaps there is a more sophisticated way, but that seems to work just fine. Basically anything that is not guaranteed to be a symbol the linker can see gets a wrapper function written in C. I think I also did this for some of libc's many types (ptrdiff_t and size_t, for example) that I shouldn't technically assume anything about. I didn't *need* portability, but I tried to work in that direction anyway. I have some other tricks, but they depend on the fact that I actually run LLVM code through CPP, which I assume most people have too m...

Jeff Cohen wrote: > VS has a 64-bit portability mode, where it will complain when it sees > non-portable code. I haven't tried it yet on LLVM, but in my experience > it will generate a *lot* of warnings. Every time a size_t or ptrdiff_t > is assigned to an int or even a long it will complain (Microsoft defines > long as 32-bits, even in win64). On the other hand, gcc defines long as > 64-bits on 64-bit Unix (so what does it do on cygwin or mingw?). The > portability warnings are still useful, but it does mean tha...

...ble to have a vector with more items than an int64_t can represent, isn't it already worth it to use size_t, which is an unsigned type? That's not true on my platform. I have 64-bit pointers so intptr_t is 64-bits, but the largest thing you can allocate is only 32-bits big so size_t (and ptrdiff_t) are 32-bits. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190612/7ecc6f56/attachment.sig>

...X in C11 K.3.4/4 which is typically equivalent to PTRDIFF_MAX. - The expectation that PTRDIFF_MAX is more or less a proxy for the largest object size is not uncommon. For example, C++'s std::count doesn't return a size_t but a iterator_traits<>::difference_type which is going to be a ptrdiff_t for things like std::vector. On Fri, May 20, 2016 at 1:31 AM, John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It could be that 32-bit systems are disappearing so rapidly that nobody > cares too much about this issue, but this blog post is still worth reading: > >...

...stdio.h was duplicately defining va_list - */ -#define _VA_LIST_DEFINED #endif #endif /* __STDARG_H */ diff --git a/c_headers/stddef.h b/c_headers/stddef.h index 3b55d42c..73549967 100644 --- a/c_headers/stddef.h +++ b/c_headers/stddef.h @@ -48,13 +48,7 @@ #if !__has_feature(modules) #define _PTRDIFF_T #endif - -/* Zig: wrap in _PTRDIFF_T_DEFINED to protect against mingw defining it twice */ -#if !defined(_PTRDIFF_T_DEFINED) typedef __PTRDIFF_TYPE__ ptrdiff_t; -#define _PTRDIFF_T_DEFINED -#endif - #endif #undef __need_ptrdiff_t #endif /* defined(__need_ptrdiff_t) */ @@ -65,24 +59,7 @@ typede...