Displaying 7 results from an estimated 7 matches for "ptrdiff_max".
2016 May 20
3
problems with objects larger than PTRDIFF_MAX
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:
http://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/
John
2016 May 20
0
problems with objects larger than PTRDIFF_MAX
...s 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! Their guidance for maximum
object size is stated to be half of SIZE_MAX 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...
2016 May 29
2
problems with objects larger than PTRDIFF_MAX
...39;t require it. But I guess you don't imply that
it's fine for clang to silently miscompile any program that works with
objects larger than 65535 bytes.
> Their guidance for maximum
> object size is stated to be half of SIZE_MAX in C11 K.3.4/4 which is
> typically equivalent to PTRDIFF_MAX.
Whose guidance? Annex K is kinda alien to the rest of the standard and
its future is not clear. See, e.g.,
http://open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm .
> - The expectation that PTRDIFF_MAX is more or less a proxy for the largest
> object size is not uncommon. For example, C+...
2016 May 29
0
problems with objects larger than PTRDIFF_MAX
...;
> Right, the standard doesn't require it. But I guess you don't imply that
> it's fine for clang to silently miscompile any program that works with
> objects larger than 65535 bytes.
I think that we should error when we can statically determine that an
object is larger than PTRDIFF_MAX.
>
>
> Their guidance for maximum
>> object size is stated to be half of SIZE_MAX in C11 K.3.4/4 which is
>> typically equivalent to PTRDIFF_MAX.
>>
>
> Whose guidance? Annex K is kinda alien to the rest of the standard and its
> future is not clear. See, e.g.,...
2017 Nov 08
2
Is it ok to allocate > half of address space?
>On 11/8/2017 9:24 AM, Nuno Lopes via llvm-dev wrote:
>> Hi,
>>
>> I was looking into the semantics of GEP inbounds and some BasicAA rules
>> and I'm wondering if it's valid in LLVM IR to allocate more than half of
>> the address space with a global variable or an alloca.
>> If that's a scenario want to consider, then we have problems :)
2010 Mar 20
1
[MODULE] COM32 module to time null-dumping a file, v1.1
..._tps(){ return 18.2; }
+
+#else /* __COM32__ */
+
+# define BUFSZ_DEF 16384
+/* Need to check what might be a "best" buffer/fetch block size here */
+
+static inline float get_tps(){ return (float)sysconf(_SC_CLK_TCK); }
+
+#endif /* __COM32__ */
+
+#ifndef SSIZE_MAX
+# define SSIZE_MAX PTRDIFF_MAX
+#endif
+/* typedef ptrdiff_t ssize_t; */
+#define BUFSZ_MAX SSIZE_MAX
+/* ssize_t max */
+#define BUFSZ_MIN 1
+#ifndef OFF_MAX
+# define OFF_MAX SIZE_MAX
+#endif
+/* typedef size_t off_t */
+#define LEN_MAX OFF_MAX
+/* off_t max */
+
+void print_cp_result_tick(int bcnt, clock_t et, float tps, in...
2019 Jun 11
10
[RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
Am Di., 11. Juni 2019 um 11:45 Uhr schrieb Zachary Turner via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> I'm personally against changing everything to signed integers. To me, this is an example of making code strictly less readable and more confusing in order to fight deficiencies in the language standard. I get the problem that it's solving, but I view this as mostly a