71–80 of 84 posts
I never had the use case to allocate 0 bytes of memory. If I would allocate 0 bytes of memory and get a pointer to it, I wouldn't care what the value of the pointer is since I am not allowed to dereference it anyways. But then again, why would I allocate 0 bytes of memory?
Earlier quoted context omitted.
If you call malloc(0) multiple times (without freeing in between) and get -1 each time, then the pointer is not unique.
But do we need a unique pointer or merely a pointer that is disjoint from all objects?
Personally I'd be less worried about uniqueness and more worried about alignment. An address of -1 would violate alignment requirements on most modern targets. But that may have been fine on the target in question; older microcontrollers tended to not have any hardware-level alignment requirements, and the C implementation could have treated all types as having alignment 1.
Earlier quoted context omitted.
As per the specification, it has to be a unique pointer. Being tasked to implement a specification typically means having to pass extensive conformance tests and having to answer for instances of noncompliance. You soon learn to follow the spec to the letter, to the best of your abilities, unless you can make a strong case to your management for each specific deviation.
But the letter is non-specific. It doesn't clarify if unique refers to unique when compared to non-zero allocations, or unique when called multiple times. The C99 standard[1] seems to have worded it more precisely: If the size of the space requested is zero, the behavior is implementation- defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned p…
-1 seems to be disjoint from all objects.
Earlier quoted context omitted.
> Noncompliant, since `malloc(0)` is specified to return a unique pointer if it's not `NULL`. I know I've seen that somewhere, but may I ask what standard you're referring to? If I recall correctly, this was an archaic stackless microcontroller. The heap support was mostly a marketing claim.
(you duped your comment under the other subthread) From C89, §7.10.3 "Memory management functions": > If the size of the space requested is > zero, the behavior is implementation-defined; the value returned shall be either a null pointer or a > unique pointer. The wording is different for C99 and POSIX, but I went back as far as possible (despite the poor source material; unlike later standards C89 is only accessible…
I wouldn't be surprised if Win3.1-looking tool chain had not implemented c89, though I'm certain it wasn't c99 compliant, which only requires that the pointer is a disjoint from any object, not unique.
It's strange that the standard has relaxed over time.
Earlier quoted context omitted.
> Each such allocation shall yield a pointer to an object disjoint from any other object. Phrasing could be slightly more clear to prevent someone from making the argument that -1 is disjoint from all objects as it does not point to an object
And if you use 0 as the value of NULL pointer, then -1 can't ever point to an object (because adding 1 to it should generate a non-NULL pointer, so that pointer comparisons are not UB). So yeah, C implementations have to reserve at least two addresses, not just one. By the way, the standard to this day allows NULL, when cast to a pointer type, to be something else than all-bits-zero pattern (and some implementations…
Can someone tell me a usecase where you want multiple allocations of size 0, each one with a unique address, and each one unique from any other allocation (hence necessarily removing that pointer from being allocated to anything else) but can't use malloc(1) instead? I think it would be much better if malloc(0) just returned 1 or -1 or something constant. If the programmer needs the allocation to have a unique addres…
Earlier quoted context omitted.
As per the specification, it has to be a unique pointer. Being tasked to implement a specification typically means having to pass extensive conformance tests and having to answer for instances of noncompliance. You soon learn to follow the spec to the letter, to the best of your abilities, unless you can make a strong case to your management for each specific deviation.
But the letter is non-specific. It doesn't clarify if unique refers to unique when compared to non-zero allocations, or unique when called multiple times. The C99 standard[1] seems to have worded it more precisely: If the size of the space requested is zero, the behavior is implementation- defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned p…
Earlier quoted context omitted.
But the letter is non-specific. It doesn't clarify if unique refers to unique when compared to non-zero allocations, or unique when called multiple times. The C99 standard[1] seems to have worded it more precisely: If the size of the space requested is zero, the behavior is implementation- defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned p…
It even replaced unique with "disjoint from any other object". -1 seems to be disjoint from all objects.
Writing a specification is hard...
Earlier quoted context omitted.
But do we need a unique pointer or merely a pointer that is disjoint from all objects?
As per the specification, it has to be a unique pointer. Being tasked to implement a specification typically means having to pass extensive conformance tests and having to answer for instances of noncompliance. You soon learn to follow the spec to the letter, to the best of your abilities, unless you can make a strong case to your management for each specific deviation.
I have two questions:
Could you please specify what have you meant by Fixed Function blocks on Adreno300+? Did you mean regular Rasterizer, DS and vertex assembler by this, or even portions of old FFP functionality just like lighting and etc from ES 1.x?
Because I think there is no need in HW 1.x support, since even Samsung in their FIMG emulated most of classic FFP functionality like combiners through shades.
I haven't investigated SGX53x drivers yet, but I think it was very same, since PVR MBX architecture was mostly abandoned in 2010.
And second question:
Why so many of early qcom android smartphones lacked GPU drivers at all? For example HTC Dream wasn't shipped with gpu drivers, as well as Magic and many Huawei models? For example, Moto droid has GPU drivers from the start.