mirrors-yuzu-emu/unicorn
1
0
Fork 0
mirror of https://github.com/yuzu-emu/unicorn synced 2024-11-24 12:58:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
unicorn/qemu/util/range.c

74 lines
2.1 KiB
C
Raw Normal View History

range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
/*
* QEMU 64-bit address ranges
*
* Copyright (c) 2015-2016 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU General Public
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
*
*/
#include "qemu/osdep.h"
#include "qemu/range.h"
/*
range: Replace internal representation of Range Range represents a range as follows. Member @start is the inclusive lower bound, member @end is the exclusive upper bound. Zero @end is special: if @start is also zero, the range is empty, else @end is to be interpreted as 2^64. No other empty ranges may occur. The range [0,2^64-1] cannot be represented. If you try to create it with range_set_bounds1(), you get the empty range instead. If you try to create it with range_set_bounds() or range_extend(), assertions fail. Before range_set_bounds() existed, the open-coded creation usually got you the empty range instead. Open deathtrap. Moreover, the code dealing with the janus-faced @end is too clever by half. Dumb this down to a more pedestrian representation: members @lob and @upb are inclusive lower and upper bounds. The empty range is encoded as @lob = 1, @upb = 0. Backports commit 6dd726a2bf1b800289d90a84d5fcb5ce7b78a8e1 from qemu
2018-02-25 05:43:17 +00:00
* Return -1 if @a < @b, 1 @a > @b, and 0 if they touch or overlap.
* Both @a and @b must not be empty.
range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
*/
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
static inline int range_compare(Range *a, Range *b)
range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
{
range: Replace internal representation of Range Range represents a range as follows. Member @start is the inclusive lower bound, member @end is the exclusive upper bound. Zero @end is special: if @start is also zero, the range is empty, else @end is to be interpreted as 2^64. No other empty ranges may occur. The range [0,2^64-1] cannot be represented. If you try to create it with range_set_bounds1(), you get the empty range instead. If you try to create it with range_set_bounds() or range_extend(), assertions fail. Before range_set_bounds() existed, the open-coded creation usually got you the empty range instead. Open deathtrap. Moreover, the code dealing with the janus-faced @end is too clever by half. Dumb this down to a more pedestrian representation: members @lob and @upb are inclusive lower and upper bounds. The empty range is encoded as @lob = 1, @upb = 0. Backports commit 6dd726a2bf1b800289d90a84d5fcb5ce7b78a8e1 from qemu
2018-02-25 05:43:17 +00:00
assert(!range_is_empty(a) && !range_is_empty(b));
/* Careful, avoid wraparound */
if (b->lob && b->lob - 1 > a->upb) {
qapi: Simplify use of range.h Calling our function g_list_insert_sorted_merged is a misnomer, since we are NOT writing a glib function. Furthermore, we are making every caller pass the same comparator function of range_merge(): any caller that would try otherwise would break in weird ways since our internal call to ranges_can_merge() is hard-coded to operate only on ranges, rather than paying attention to the caller's comparator. Better is to fix things so that callers don't have to care about our internal comparator, by picking a function name and updating the parameter type away from a gratuitous use of void*, to make it obvious that we are operating specifically on a list of ranges and not a generic list. Plus, refactoring the code here will make it easier to plug a memory leak in the next patch. range_compare() is now internal only, and moves to the .c file. Backports commit 7c47959d0cb05db43014141a156ada0b6d53a750 from qemu
2018-02-25 05:02:37 +00:00
return -1;
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
}
range: Replace internal representation of Range Range represents a range as follows. Member @start is the inclusive lower bound, member @end is the exclusive upper bound. Zero @end is special: if @start is also zero, the range is empty, else @end is to be interpreted as 2^64. No other empty ranges may occur. The range [0,2^64-1] cannot be represented. If you try to create it with range_set_bounds1(), you get the empty range instead. If you try to create it with range_set_bounds() or range_extend(), assertions fail. Before range_set_bounds() existed, the open-coded creation usually got you the empty range instead. Open deathtrap. Moreover, the code dealing with the janus-faced @end is too clever by half. Dumb this down to a more pedestrian representation: members @lob and @upb are inclusive lower and upper bounds. The empty range is encoded as @lob = 1, @upb = 0. Backports commit 6dd726a2bf1b800289d90a84d5fcb5ce7b78a8e1 from qemu
2018-02-25 05:43:17 +00:00
if (a->lob && a->lob - 1 > b->upb) {
qapi: Simplify use of range.h Calling our function g_list_insert_sorted_merged is a misnomer, since we are NOT writing a glib function. Furthermore, we are making every caller pass the same comparator function of range_merge(): any caller that would try otherwise would break in weird ways since our internal call to ranges_can_merge() is hard-coded to operate only on ranges, rather than paying attention to the caller's comparator. Better is to fix things so that callers don't have to care about our internal comparator, by picking a function name and updating the parameter type away from a gratuitous use of void*, to make it obvious that we are operating specifically on a list of ranges and not a generic list. Plus, refactoring the code here will make it easier to plug a memory leak in the next patch. range_compare() is now internal only, and moves to the .c file. Backports commit 7c47959d0cb05db43014141a156ada0b6d53a750 from qemu
2018-02-25 05:02:37 +00:00
return 1;
}
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
return 0;
qapi: Simplify use of range.h Calling our function g_list_insert_sorted_merged is a misnomer, since we are NOT writing a glib function. Furthermore, we are making every caller pass the same comparator function of range_merge(): any caller that would try otherwise would break in weird ways since our internal call to ranges_can_merge() is hard-coded to operate only on ranges, rather than paying attention to the caller's comparator. Better is to fix things so that callers don't have to care about our internal comparator, by picking a function name and updating the parameter type away from a gratuitous use of void*, to make it obvious that we are operating specifically on a list of ranges and not a generic list. Plus, refactoring the code here will make it easier to plug a memory leak in the next patch. range_compare() is now internal only, and moves to the .c file. Backports commit 7c47959d0cb05db43014141a156ada0b6d53a750 from qemu
2018-02-25 05:02:37 +00:00
}
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
/* Insert @data into @list of ranges; caller no longer owns @data */
qapi: Simplify use of range.h Calling our function g_list_insert_sorted_merged is a misnomer, since we are NOT writing a glib function. Furthermore, we are making every caller pass the same comparator function of range_merge(): any caller that would try otherwise would break in weird ways since our internal call to ranges_can_merge() is hard-coded to operate only on ranges, rather than paying attention to the caller's comparator. Better is to fix things so that callers don't have to care about our internal comparator, by picking a function name and updating the parameter type away from a gratuitous use of void*, to make it obvious that we are operating specifically on a list of ranges and not a generic list. Plus, refactoring the code here will make it easier to plug a memory leak in the next patch. range_compare() is now internal only, and moves to the .c file. Backports commit 7c47959d0cb05db43014141a156ada0b6d53a750 from qemu
2018-02-25 05:02:37 +00:00
GList *range_list_insert(GList *list, Range *data)
range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
{
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
GList *l;
range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
range: Eliminate direct Range member access Users of struct Range mess liberally with its members, which makes refactoring hard. Create a set of methods, and convert all users to call them instead of accessing members. The methods have carefully worded contracts, and use assertions to check them. Backports commit a0efbf16604770b9d805bcf210ec29942321134f from qemu
2018-02-25 05:39:36 +00:00
assert(!range_is_empty(data));
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
/* Skip all list elements strictly less than data */
for (l = list; l && range_compare(l->data, data) < 0; l = l->next) {
range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
}
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
if (!l || range_compare(l->data, data) > 0) {
/* Rest of the list (if any) is strictly greater than @data */
return g_list_insert_before(list, l, data);
range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
}
qapi: Fix memleak in string visitors on int lists Commit 7f8f9ef1 introduced the ability to store a list of integers as a sorted list of ranges, but when merging ranges, it leaks one or more ranges. It was also using range_get_last() incorrectly within range_compare() (a range is a start/end pair, but range_get_last() is for start/len pairs), and will also mishandle a range ending in UINT64_MAX (remember, we document that no range covers 2**64 bytes, but that ranges that end on UINT64_MAX have end < begin). The whole merge algorithm was rather complex, and included unnecessary passes over data within glib functions, and enough indirection to make it hard to easily plug the data leaks. Since we are already hard-coding things to a list of ranges, just rewrite the thing to open-code the traversal and comparisons, by making the range_compare() helper function give us an answer that is easier to use, at which point we avoid the need to pass any callbacks to g_list_*(). Then by reusing range_extend() instead of duplicating effort with range_merge(), we cover the corner cases correctly. Drop the now-unused range_merge() and ranges_can_merge(). Doing this lets test-string-{input,output}-visitor pass under valgrind without leaks. Backports commit db486cc334aafd3dbdaf107388e37fc3d6d3e171 from qemu
2018-02-25 05:05:52 +00:00
/* Current list element overlaps @data, merge the two */
range_extend(l->data, data);
g_free(data);
/* Merge any subsequent list elements that now also overlap */
while (l->next && range_compare(l->data, l->next->data) == 0) {
GList *new_l;
range_extend(l->data, l->next->data);
g_free(l->next->data);
new_l = g_list_delete_link(list, l->next);
assert(new_l == list);
range: Create range.c for code that should not be inline g_list_insert_sorted_merged() is rather large to be an inline function; move it to its own file. range_merge() and ranges_can_merge() can likewise move, as they are only used internally. Also, it becomes obvious that the condition within range_merge() is already satisfied by its caller, and that the return value is not used. The diffstat is misleading, because of the copyright boilerplate. Backports commit fec0fc0a13ac7f1a1130433a6740cd850c3db34a from qemu
2018-02-25 04:57:04 +00:00
}
return list;
}
Reference in a new issue Copy permalink