AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-11-12 16:20:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
97aa92263a
glibc/localedata/locales/C

201 lines
5.3 KiB
Plaintext
Raw Normal View History

Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
escape_char /
comment_char %
% Locale for C locale in UTF-8
LC_IDENTIFICATION
title "C locale"
source ""
address ""
contact ""
email "bug-glibc-locales@gnu.org"
tel ""
fax ""
language ""
territory ""
localedata: Adjust C.UTF-8 to align with C/POSIX. We have had one downstream report from Canonical [1] that an rrdtool test was broken by the differences in LC_TIME that we had in the non-builtin C locale (C.UTF-8). If one application has an issue there are going to be others, and so with this commit we review and fix all the issues that cause the builtin C locale to be different from C.UTF-8, which includes: * mon_decimal_point should be empty e.g. "" - Depends on mon_decimal_point_wc fix. * negative_sign should be empty e.g. "" * week should be aligned with the builtin C/POSIX locale * d_fmt corrected with escaped slashes e.g. "%m//%d//%y" * yesstr and nostr should be empty e.g. "" * country_ab2 and country_ab3 should be empty e.g. "" We bump LC_IDENTIFICATION version and adjust the date to indicate the change in the locale. A new tst-c-utf8-consistency test is added to ensure consistency between C/POSIX and C.UTF-8. Tested on x86_64 and i686 without regression. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135703.html Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-01-31 05:34:42 +00:00
revision "2.1"
date "2022-01-30"
Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
category "i18n:2012";LC_IDENTIFICATION
category "i18n:2012";LC_CTYPE
category "i18n:2012";LC_COLLATE
category "i18n:2012";LC_TIME
category "i18n:2012";LC_NUMERIC
category "i18n:2012";LC_MONETARY
category "i18n:2012";LC_MESSAGES
category "i18n:2012";LC_PAPER
category "i18n:2012";LC_NAME
category "i18n:2012";LC_ADDRESS
category "i18n:2012";LC_TELEPHONE
category "i18n:2012";LC_MEASUREMENT
END LC_IDENTIFICATION
LC_CTYPE
% Include only the i18n character type classes without any of the
% transliteration that i18n uses by default.
copy "i18n_ctype"
% Include the neutral transliterations. The builtin C and
% POSIX locales have +1600 transliterations that are built into
% the locales, and these are a superset of those.
translit_start
include "translit_neutral";""
% We must use '?' for default_missing because the transliteration
% framework includes it directly into the output and so it must
% be compatible with ASCII if that is the target character set.
default_missing <U003F>
translit_end
% Include the transliterations that can convert combined characters.
% These are generally expected by users.
translit_start
include "translit_combining";""
translit_end
END LC_CTYPE
LC_COLLATE
% The keyword 'codepoint_collation' in any part of any LC_COLLATE
% immediately discards all collation information and causes the
% locale to use strcmp/wcscmp for collation comparison. This is
% exactly what is needed for C (ASCII) or C.UTF-8.
codepoint_collation
END LC_COLLATE
LC_MONETARY
% This is the 14652 i18n fdcc-set definition for the LC_MONETARY
% category (except for the int_curr_symbol and currency_symbol, they are
% empty in the 14652 i18n fdcc-set definition and also empty in
% glibc/locale/C-monetary.c.).
int_curr_symbol ""
currency_symbol ""
localedata: Adjust C.UTF-8 to align with C/POSIX. We have had one downstream report from Canonical [1] that an rrdtool test was broken by the differences in LC_TIME that we had in the non-builtin C locale (C.UTF-8). If one application has an issue there are going to be others, and so with this commit we review and fix all the issues that cause the builtin C locale to be different from C.UTF-8, which includes: * mon_decimal_point should be empty e.g. "" - Depends on mon_decimal_point_wc fix. * negative_sign should be empty e.g. "" * week should be aligned with the builtin C/POSIX locale * d_fmt corrected with escaped slashes e.g. "%m//%d//%y" * yesstr and nostr should be empty e.g. "" * country_ab2 and country_ab3 should be empty e.g. "" We bump LC_IDENTIFICATION version and adjust the date to indicate the change in the locale. A new tst-c-utf8-consistency test is added to ensure consistency between C/POSIX and C.UTF-8. Tested on x86_64 and i686 without regression. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135703.html Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-01-31 05:34:42 +00:00
mon_decimal_point ""
Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
mon_thousands_sep ""
mon_grouping -1
positive_sign ""
localedata: Adjust C.UTF-8 to align with C/POSIX. We have had one downstream report from Canonical [1] that an rrdtool test was broken by the differences in LC_TIME that we had in the non-builtin C locale (C.UTF-8). If one application has an issue there are going to be others, and so with this commit we review and fix all the issues that cause the builtin C locale to be different from C.UTF-8, which includes: * mon_decimal_point should be empty e.g. "" - Depends on mon_decimal_point_wc fix. * negative_sign should be empty e.g. "" * week should be aligned with the builtin C/POSIX locale * d_fmt corrected with escaped slashes e.g. "%m//%d//%y" * yesstr and nostr should be empty e.g. "" * country_ab2 and country_ab3 should be empty e.g. "" We bump LC_IDENTIFICATION version and adjust the date to indicate the change in the locale. A new tst-c-utf8-consistency test is added to ensure consistency between C/POSIX and C.UTF-8. Tested on x86_64 and i686 without regression. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135703.html Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-01-31 05:34:42 +00:00
negative_sign ""
Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
int_frac_digits -1
frac_digits -1
p_cs_precedes -1
int_p_sep_by_space -1
p_sep_by_space -1
n_cs_precedes -1
int_n_sep_by_space -1
n_sep_by_space -1
p_sign_posn -1
n_sign_posn -1
%
END LC_MONETARY
LC_NUMERIC
% This is the POSIX Locale definition for
% the LC_NUMERIC category.
%
decimal_point "."
thousands_sep ""
grouping -1
END LC_NUMERIC
LC_TIME
% This is the POSIX Locale definition for the LC_TIME category with the
% exception that time is per ISO 8601 and 24-hour.
%
% Abbreviated weekday names (%a)
abday "Sun";"Mon";"Tue";"Wed";"Thu";"Fri";"Sat"
% Full weekday names (%A)
day "Sunday";"Monday";"Tuesday";"Wednesday";"Thursday";/
"Friday";"Saturday"
% Abbreviated month names (%b)
abmon "Jan";"Feb";"Mar";"Apr";"May";"Jun";"Jul";"Aug";"Sep";/
"Oct";"Nov";"Dec"
% Full month names (%B)
mon "January";"February";"March";"April";"May";"June";"July";/
"August";"September";"October";"November";"December"
% Week description, consists of three fields:
% 1. Number of days in a week.
% 2. Gregorian date that is a first weekday (19971130 for Sunday, 19971201 for Monday).
% 3. The weekday number to be contained in the first week of the year.
%
% ISO 8601 conforming applications should use the values 7, 19971201 (a
% Monday), and 4 (Thursday), respectively.
localedata: Adjust C.UTF-8 to align with C/POSIX. We have had one downstream report from Canonical [1] that an rrdtool test was broken by the differences in LC_TIME that we had in the non-builtin C locale (C.UTF-8). If one application has an issue there are going to be others, and so with this commit we review and fix all the issues that cause the builtin C locale to be different from C.UTF-8, which includes: * mon_decimal_point should be empty e.g. "" - Depends on mon_decimal_point_wc fix. * negative_sign should be empty e.g. "" * week should be aligned with the builtin C/POSIX locale * d_fmt corrected with escaped slashes e.g. "%m//%d//%y" * yesstr and nostr should be empty e.g. "" * country_ab2 and country_ab3 should be empty e.g. "" We bump LC_IDENTIFICATION version and adjust the date to indicate the change in the locale. A new tst-c-utf8-consistency test is added to ensure consistency between C/POSIX and C.UTF-8. Tested on x86_64 and i686 without regression. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135703.html Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-01-31 05:34:42 +00:00
%
% This field is consciously aligned with the builtin C/POSIX locale.
week 7;19971130;4
Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
first_weekday 1
first_workday 2
% Appropriate date and time representation (%c)
d_t_fmt "%a %b %e %H:%M:%S %Y"
% Appropriate date representation (%x)
localedata: Adjust C.UTF-8 to align with C/POSIX. We have had one downstream report from Canonical [1] that an rrdtool test was broken by the differences in LC_TIME that we had in the non-builtin C locale (C.UTF-8). If one application has an issue there are going to be others, and so with this commit we review and fix all the issues that cause the builtin C locale to be different from C.UTF-8, which includes: * mon_decimal_point should be empty e.g. "" - Depends on mon_decimal_point_wc fix. * negative_sign should be empty e.g. "" * week should be aligned with the builtin C/POSIX locale * d_fmt corrected with escaped slashes e.g. "%m//%d//%y" * yesstr and nostr should be empty e.g. "" * country_ab2 and country_ab3 should be empty e.g. "" We bump LC_IDENTIFICATION version and adjust the date to indicate the change in the locale. A new tst-c-utf8-consistency test is added to ensure consistency between C/POSIX and C.UTF-8. Tested on x86_64 and i686 without regression. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135703.html Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-01-31 05:34:42 +00:00
d_fmt "%m//%d//%y"
Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
% Appropriate time representation (%X)
t_fmt "%H:%M:%S"
% Appropriate AM/PM time representation (%r)
t_fmt_ampm "%I:%M:%S %p"
% Equivalent of AM/PM (%p)
am_pm "AM";"PM"
% Appropriate date representation (date(1))
date_fmt "%a %b %e %H:%M:%S %Z %Y"
END LC_TIME
LC_MESSAGES
% This is the POSIX Locale definition for
% the LC_NUMERIC category.
%
yesexpr "^[yY]"
noexpr "^[nN]"
localedata: Adjust C.UTF-8 to align with C/POSIX. We have had one downstream report from Canonical [1] that an rrdtool test was broken by the differences in LC_TIME that we had in the non-builtin C locale (C.UTF-8). If one application has an issue there are going to be others, and so with this commit we review and fix all the issues that cause the builtin C locale to be different from C.UTF-8, which includes: * mon_decimal_point should be empty e.g. "" - Depends on mon_decimal_point_wc fix. * negative_sign should be empty e.g. "" * week should be aligned with the builtin C/POSIX locale * d_fmt corrected with escaped slashes e.g. "%m//%d//%y" * yesstr and nostr should be empty e.g. "" * country_ab2 and country_ab3 should be empty e.g. "" We bump LC_IDENTIFICATION version and adjust the date to indicate the change in the locale. A new tst-c-utf8-consistency test is added to ensure consistency between C/POSIX and C.UTF-8. Tested on x86_64 and i686 without regression. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135703.html Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-01-31 05:34:42 +00:00
yesstr ""
nostr ""
Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
END LC_MESSAGES
LC_PAPER
% This is the ISO/IEC 14652 "i18n" definition for
% the LC_PAPER category.
% (A4 paper, this is also used in the built in C/POSIX
% locale in glibc/locale/C-paper.c)
height 297
width 210
END LC_PAPER
LC_NAME
% This is the ISO/IEC 14652 "i18n" definition for
% the LC_NAME category.
% (also used in the built in C/POSIX locale in glibc/locale/C-name.c)
name_fmt "%p%t%g%t%m%t%f"
END LC_NAME
LC_ADDRESS
% This is the ISO/IEC 14652 "i18n" definition for
% the LC_ADDRESS category.
% (also used in the built in C/POSIX locale in glibc/locale/C-address.c)
postal_fmt "%a%N%f%N%d%N%b%N%s %h %e %r%N%C-%z %T%N%c%N"
localedata: Adjust C.UTF-8 to align with C/POSIX. We have had one downstream report from Canonical [1] that an rrdtool test was broken by the differences in LC_TIME that we had in the non-builtin C locale (C.UTF-8). If one application has an issue there are going to be others, and so with this commit we review and fix all the issues that cause the builtin C locale to be different from C.UTF-8, which includes: * mon_decimal_point should be empty e.g. "" - Depends on mon_decimal_point_wc fix. * negative_sign should be empty e.g. "" * week should be aligned with the builtin C/POSIX locale * d_fmt corrected with escaped slashes e.g. "%m//%d//%y" * yesstr and nostr should be empty e.g. "" * country_ab2 and country_ab3 should be empty e.g. "" We bump LC_IDENTIFICATION version and adjust the date to indicate the change in the locale. A new tst-c-utf8-consistency test is added to ensure consistency between C/POSIX and C.UTF-8. Tested on x86_64 and i686 without regression. [1] https://sourceware.org/pipermail/libc-alpha/2022-January/135703.html Co-authored-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-01-31 05:34:42 +00:00
% The abbreviated 2 char and 3 char should be set to empty strings to
% match the C/POSIX locale.
country_ab2 ""
country_ab3 ""
Add generic C.UTF-8 locale (Bug 17318) We add a new C.UTF-8 locale. This locale is not builtin to glibc, but is provided as a distinct locale. The locale provides full support for UTF-8 and this includes full code point sorting via STRCMP-based collation (strcmp or wcscmp). The collation uses a new keyword 'codepoint_collation' which drops all collation rules and generates an empty zero rules collation to enable STRCMP usage in collation. This ensures that we get full code point sorting for C.UTF-8 with a minimal 1406 bytes of overhead (LC_COLLATE structure information and ASCII collating tables). The new locale is added to SUPPORTED. Minimal test data for specific code points (minus those not supported by collate-test) is provided in C.UTF-8.in, and this verifies code point sorting is working reasonably across the range. The locale was tested manually with the full set of code points without failure. The locale is harmonized with locales already shipping in various downstream distributions. A new tst-iconv9 test is added which verifies the C.UTF-8 locale is generally usable. Testing for fnmatch, regexec, and recomp is provided by extending bug-regex1, bugregex19, bug-regex4, bug-regex6, transbug, tst-fnmatch, tst-regcomp-truncated, and tst-regex to use C.UTF-8. Tested on x86_64 or i686 without regression. Reviewed-by: Florian Weimer <fweimer@redhat.com>
2021-09-01 19:19:19 +00:00
END LC_ADDRESS
LC_TELEPHONE
% This is the ISO/IEC 14652 "i18n" definition for
% the LC_TELEPHONE category.
% "+%c %a %l"
tel_int_fmt "+%c %a %l"
% (also used in the built in C/POSIX locale in glibc/locale/C-telephone.c)
END LC_TELEPHONE
LC_MEASUREMENT
% This is the ISO/IEC 14652 "i18n" definition for
% the LC_MEASUREMENT category.
% (same as in the built in C/POSIX locale in glibc/locale/C-measurement.c)
%metric
measurement 1
END LC_MEASUREMENT
Reference in New Issue Copy Permalink