| 1759 | in LINE specified by KEY. */ |
| 1760 | |
| 1761 | ATTRIBUTE_PURE |
| 1762 | static char * |
| 1763 | limfield (struct line const *line, struct keyfield const *key) |
| 1764 | { |
| 1765 | char *ptr = line->text, *lim = ptr + line->length - 1; |
| 1766 | size_t eword = key->eword, echar = key->echar; |
| 1767 | |
| 1768 | if (echar == 0) |
| 1769 | eword++; /* Skip all of end field. */ |
| 1770 | |
| 1771 | /* Move PTR past EWORD fields or to one past the last byte on LINE, |
| 1772 | whichever comes first. If there are more than EWORD fields, leave |
| 1773 | PTR pointing at the beginning of the field having zero-based index, |
| 1774 | EWORD. If a delimiter character was specified (via -t), then that |
| 1775 | 'beginning' is the first character following the delimiting TAB. |
| 1776 | Otherwise, leave PTR pointing at the first 'blank' character after |
| 1777 | the preceding field. */ |
| 1778 | if (tab != TAB_DEFAULT) |
| 1779 | while (ptr < lim && eword--) |
| 1780 | { |
| 1781 | char *sep = memchr (ptr, tab, lim - ptr); |
| 1782 | ptr = sep ? sep : lim; |
| 1783 | if (ptr < lim && (eword || echar)) |
| 1784 | ++ptr; |
| 1785 | } |
| 1786 | else |
| 1787 | while (ptr < lim && eword--) |
| 1788 | { |
| 1789 | while (ptr < lim && blanks[to_uchar (*ptr)]) |
| 1790 | ++ptr; |
| 1791 | while (ptr < lim && !blanks[to_uchar (*ptr)]) |
| 1792 | ++ptr; |
| 1793 | } |
| 1794 | |
| 1795 | #ifdef POSIX_UNSPECIFIED |
| 1796 | /* The following block of code makes GNU sort incompatible with |
| 1797 | standard Unix sort, so it's ifdef'd out for now. |
| 1798 | The POSIX spec isn't clear on how to interpret this. |
| 1799 | FIXME: request clarification. |
| 1800 | |
| 1801 | From: kwzh@gnu.ai.mit.edu (Karl Heuer) |
| 1802 | Date: Thu, 30 May 96 12:20:41 -0400 |
| 1803 | [Translated to POSIX 1003.1-2001 terminology by Paul Eggert.] |
| 1804 | |
| 1805 | [...]I believe I've found another bug in 'sort'. |
| 1806 | |
| 1807 | $ cat /tmp/sort.in |
| 1808 | a b c 2 d |
| 1809 | pq rs 1 t |
| 1810 | $ textutils-1.15/src/sort -k1.7,1.7 </tmp/sort.in |
| 1811 | a b c 2 d |
| 1812 | pq rs 1 t |
| 1813 | $ /bin/sort -k1.7,1.7 </tmp/sort.in |
| 1814 | pq rs 1 t |
| 1815 | a b c 2 d |
| 1816 | |
| 1817 | Unix sort produced the answer I expected: sort on the single character |
| 1818 | in column 7. GNU sort produced different results, because it disagrees |
no test coverage detected