why binsearch's high is set to outside the limit of array? - arrays

Question

I was studying K&R, my program was to count the number of keytabs appeared in a C program as a result I made a struct in ascending order with count values 0:
struct key {
char *word;
int count;
} keytab[] = {
"auto", 0,
"break", 0,
"case", 0,
"char", 0,
"const", 0,
"continue", 0,
"default", 0,
"do", 0,
"else", 0,
"for", 0,
"float", 0,
"goto", 0,
"if", 0,
"int", 0,
"long", 0,
"return", 0,
"struct", 0,
"unsigned", 0,
"void", 0,
"volatile", 0,
"while", 0,
};
now whenever a new non-string word is encountered it will search (using binsearch) in the keytab array and increase its count.
However, I was using a function binsearch returning a pointer of type struct key * for the word (now keyword) that is successfully found in the array. And then increment its count:
struct key *binsearch(char *word, struct key *tab, int n)
{
int cond;
struct key *low = &tab[0];
struct key *high = &tab[n];
struct key *mid;
while (low < high) {
mid = low + (high - low) / 2;
if ((cond = strcmp(word, mid->word)) < 0)
high = mid;
else if (cond > 0)
low = mid + 1;
else
return mid;
}
return NULL;
}
Here is the full code:
#include <windows.h>
#include "useful.c"
#include <string.h>
void color(int);
struct key *binsearch(char *, struct key *, int);
struct key {
char *word;
int count;
} keytab[] = {
"auto", 0,
"break", 0,
"case", 0,
"char", 0,
"const", 0,
"continue", 0,
"default", 0,
"do", 0,
"else", 0,
"for", 0,
"float", 0,
"goto", 0,
"if", 0,
"int", 0,
"long", 0,
"return", 0,
"struct", 0,
"unsigned", 0,
"void", 0,
"volatile", 0,
"while", 0,
};
#define NKEYS (sizeof keytab / sizeof(struct key))
int main()
{
color(3);
char word[MAXWORD];
struct key *p;
while (getword(word, MAXWORD) != EOF)
if (isalpha(word[0]))
if ((p = binsearch(word, keytab, NKEYS)) != NULL)
p->count++;
for (p = keytab; p < keytab + NKEYS; p++)
if (p->count > 0)
printf("%4d %s\n", p->count, p->word);
return 0;
}
struct key *binsearch(char *word, struct key *tab, int n)
{
int cond;
struct key *low = &tab[0];
struct key *high = &tab[n];
struct key *mid;
while (low < high) {
mid = low + (high - low) / 2;
if ((cond = strcmp(word, mid->word)) < 0)
high = mid;
else if (cond > 0)
low = mid + 1;
else
return mid;
}
return NULL;
}
void color(int i) {
HANDLE k;
k = GetStdHandle(STD_OUTPUT_HANDLE);
SetConsoleTextAttribute(k, i);
}
on running the code on itself it gives the following output:
4 char
2 else
5 if
7 int
3 return
9 struct
2 void
2 while
on doing high = &tab[n - 1] and high = mid - 1
the following is the output on the new code:
2 else
5 if
7 int
3 return
9 struct
2 void
as one can see while and char are missing, I don't know why?
My question is why high = &tab[n] and not high = &tab[n-1] and why high = mid in while loop like the traditional binsearch.
If you find any other error or bug in the program, please tell me that also.
useful.c contains the following code:
int getword(char *word, int lim)
{
int c, getch(void);
void ungetch(int);
char *w = word;
while (isspace(c = getch()))
;
if (c != EOF)
*w++ = c;
if (c == '\"') {
for (; --lim > 0 && (*w = c = getch()) != '"' && (c != EOF); w++)
;
if (c == EOF)
*w = '\0';
else
*++w = '\0';
if (*(--w) == '\"')
return '\"';
return word[1];
}
if (c == '#') {
for (; --lim > 0 && (*w = c = getch()) != '\n' && (c != EOF); w++)
;
if (c == EOF)
*w = '\0';
else
*++w = '\0';
return word[0];
}
if (!isalpha(c)) {
*w = '\0';
return c;
}
for (; --lim > 0; w++)
if (!isalnum(*w = getch())) {
ungetch(*w);
break;
}
*w = '\0';
return word[0];
}
#define BUFSIZE 1000
static int buf[BUFSIZE];
static int bufp = 0;
int getch(void)
{
return (bufp > 0) ? buf[--bufp] : getchar();
}
void ungetch(int c)
{
if (bufp >= BUFSIZE)
printf("Buffer full\n");
else
buf[bufp++] = c;
}
And the standard headers <stdio.h>, <stdlib.h>, <ctype.h>

Answer 1

why binsearch's high is set to outside the limit of array?
why high = &tab[n] and not high = &tab[n-1]
There may be no inside: n == 0.
Avoids UB.
Given an object address *(perhaps allocated) and size n, there are only 2 pointers certainly computable for all n: &p[0] and &p[n]. They point to the same place when n==0.
&tab[n-1] is a risk without n qualification.
Consider the below which has both low and high as "inside" the array using a classical high = mid - 1; / low = mid + 1; approach. It searches slightly faster.
struct key *binsearch_alt(char *word, struct key *tab, int n) {
int cond;
struct key *low = &tab[0];
// struct key *high = &tab[n];
struct key *high = &tab[n - 1]; // Change
struct key *mid;
// while(low<high) {
while(low <= high) { // Change
mid = low + (high-low)/2;
if((cond = strcmp(word, mid->word)) < 0)
// high = mid;
high = mid - 1; // Change
else if (cond>0)
low = mid + 1;
else
return mid;
}
return NULL;
}
With high = mid - 1; and mid == word we have undefined behavior (UB) and need to avoid that.
Also what happens when n == 0? &tab[n - 1]; is undefined behavior (UB).
True, we could add a test up front
if (n <= 0) return NULL;
yet it appeared the author chose a slightly different binary search.
Notice the original and binsearch_alt() are also UB with &tab[n]; when n < 0. One of the reasons to consider an unsigned n.
Candidate alternative code with no trouble with small n and performs the slight faster search than original.
const struct key* binsearch_alt2(const char *word, size_t n, const struct key[n]) {
while (n > 0) {
size_t mid = n / 2;
int cond = strcmp(word, tab[mid].word);
if (cond < 0) {
n = mid;
} else if (cond > 0) {
tab += mid + 1;
n -= mid + 1;
} else {
return &tab[mid];
}
}
return NULL;
}

Answer 2

When performing a binary search, we keep track of some interval where the candidate might be. If the interval contains exactly the elements indexed 3, 4, and 5, we could represent that interval as “all the indices i for 3 ≤ i ≤ 5” or “all the indices i for 3 ≤ i < 6” or “all the indices i for 2 < i ≤ 5” or even “all the indices i for 13 ≤ i+10 ≤ 15”. These are all mathematically equivalent: They identify the same set of indices.
So, as far as program correctness matters, it does not matter which form of representation we use, as long as the code is written consistently for the chosen representation. A common method of selecting the representation is to avoid having extra +1 and -1 in the program. Reducing clutter often helps avoid bugs, by making it easier to read and edit programs. If we have just tested midpoint and ruled it out, it is slightly less cluttered to set high = midpoint; instead of high = midpoint-1;.
Intervals described as “a ≤ i < b” are described as half-open intervals; it includes a (is closed on the a side) but excludes b (is open on the b side). I find they have some other nice properties. For example, the interval “2a ≤ i < 2b” contains exactly twice as many integers as “a ≤ i < b”, but the interval “2a ≤ i ≤ 2b” does not contain exactly twice as many as “a ≤ i ≤ b”. (6 ≤ i < 12 contains 6 integers, twice as many as the 3 in 3 ≤ i < 6, but 6 ≤ i ≤ 10 contains 5 integers, not twice as many as the 3 in 3 ≤ i ≤ 5.)

Answer 3

If you change the semantics for high from a pointer one past the last element of the array to pointer to the last element of the slice, you must change high = &tab[n - 1] and high = mid - 1 but also while (low <= high)
Note however that this approach assumes that computing a pointer to an element before the beginning if the array is possible and yields a pointer that compares less to &tab[0]. You would hit this case if searching for a word less than the first keyword, eg "a".
While this would probably work on modern systems with linear memory space, this behavior is not defined by the C Standard, so your program might malfunction even on systems with this feature. Do not rely on undefined behavior, use the classic approach where the upper bound is a pointer one past the ending element. The C Standard has special provisions to guarantee that it works and it even allows for empty slices, which may be useful to represent an empty set of words.