bitbucket-pipelines.yml: Change `make check` to `make distcheck`
Now that `make distcheck` should succeed, we can just use it as it
internally does `make check`. This patch changes the BitBucket
pipeline file to do so.
/*
* Purple
*
* Purple is the legal property of its developers, whose names are too
* numerous to list here. Please refer to the COPYRIGHT file distributed
* with this source distribution
*
* This program 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 program 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
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA
*/
#ifndef PURPLE_TRIE_H
#define PURPLE_TRIE_H
/**
* SECTION:trie
* @include:trie.h
* @section_id: libpurple-trie
* @short_description: a structure for linear-time text searching
* @title: Tries
*
* A #PurpleTrie is a structure for quick searching of multiple phrases within
* a text. It's intended for repeated searches of the same set of patterns
* within multiple source texts (or a single, big one).
*
* It's preparation time is <literal>O(p)</literal>, where <literal>p</literal>
* is the total length of searched phrases. In current implementation, the
* internal structure is invalidated after every modification of the
* #PurpleTrie's contents, so it's not efficient to do alternating modifications
* and searches. Search time does not depend on patterns being stored within
* a trie and is always <literal>O(n)</literal>, where <literal>n</literal> is
* the size of a text.
*
* Its main drawback is a significant memory usage - every internal trie node
* needs about 1kB of memory on 32-bit machine and 2kB on 64-bit. Fortunately,
* the trie grows slower when more words (with common prefixes) are added.
* We could avoid invalidating the whole tree when altering it, but it would
* require figuring out, how to update <literal>longest_suffix</literal> fields